System and method for managing and configuring attributes of internet of things (iot) devices

ABSTRACT

A system and method are described for managing attributes in an IoT system. For example, one embodiment of a machine-readable medium comprises program code stored thereon which, when executed by a machine, causes the machine to perform the operations of: specifying a plurality of attributes for a corresponding plurality of items of data managed in an Internet of Things (IoT) device and/or an IoT service; associating one or more ancillary attributes with one or more of the plurality of attributes, the ancillary attributes to specify attribute configurations and/or interdependencies between one or more of the plurality of attributes; evaluating the one or more ancillary attributes to ensure compliance with predefined constraints associated with the plurality of items of data; generating an indication of compliance if the one or more ancillary attributes are in compliance with the predefined constraints; and generating an indication of non-compliance if the one or more ancillary attributes are not in compliance with the predefined constraints.

BACKGROUND Field of the Invention

This invention relates generally to the field of computer systems. Moreparticularly, the invention relates to a system and method for managingand configuring attributes of IoT devices.

Description of the Related Art

The “Internet of Things” refers to the interconnection ofuniquely-identifiable embedded devices within the Internetinfrastructure. Ultimately, IoT is expected to result in new,wide-ranging types of applications in which virtually any type ofphysical thing may provide information about itself or its surroundingsand/or may be controlled remotely via client devices over the Internet.

IoT development and adoption has been slow due to issues related toconnectivity, power, and a lack of standardization. For example, oneobstacle to IoT development and adoption is that no standard platformexists to allow developers to design and offer new IoT devices andservices. In order enter into the IoT market, a developer must designthe entire IoT platform from the ground up, including the networkprotocols and infrastructure, hardware, software and services requiredto support the desired IoT implementation. As a result, each provider ofIoT devices uses proprietary techniques for designing and connecting theIoT devices, making the adoption of multiple types of IoT devicesburdensome for end users. Another obstacle to IoT adoption is thedifficulty associated with connecting and powering IoT devices.Connecting appliances such as refrigerators, garage door openers,environmental sensors, home security sensors/controllers, etc, forexample, requires an electrical source to power each connected IoTdevice, and such an electrical source is often not conveniently located.

Another problem which exists is that the wireless technologies used tointerconnect IoT devices such as Bluetooth LE (BTLE) are generally shortrange technologies. Thus, if the data collection hub for an IoTimplementation is outside the range of an IoT device, the IoT devicewill not be able to transmit data to the IoT hub (and vice versa).Consequently, techniques are needed which would allow an IoT device toprovide data to an IoT hub (or other IoT device) which is out of range.

Additionally, current IoT implementations which rely on wirelesscommunication protocols such as BTLE do not provide adequate securitymeasures. Accordingly, additional techniques are needed to improvesecurity in IoT implementations.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained from thefollowing detailed description in conjunction with the followingdrawings, in which:

FIGS. 1A-B illustrates different embodiments of an IoT systemarchitecture;

FIG. 2 illustrates an IoT device in accordance with one embodiment ofthe invention;

FIG. 3 illustrates an IoT hub in accordance with one embodiment of theinvention;

FIG. 4A-B illustrate embodiments of the invention for controlling andcollecting data from IoT devices, and generating notifications;

FIG. 5 illustrates embodiments of the invention for collecting data fromIoT devices and generating notifications from an IoT hub and/or IoTservice;

FIG. 6 illustrates one embodiment of a system in which an intermediarymobile device collects data from a stationary IoT device and providesthe data to an IoT hub;

FIG. 7 illustrates intermediary connection logic implemented in oneembodiment of the invention;

FIG. 8 illustrates a method in accordance with one embodiment of theinvention;

FIG. 9A illustrates an embodiment in which program code and data updatesare provided to the IoT device;

FIG. 9B illustrates an embodiment of a method in which program code anddata updates are provided to the IoT device;

FIG. 10 illustrates a high level view of one embodiment of a securityarchitecture;

FIG. 11 illustrates one embodiment of an architecture in which asubscriber identity module (SIM) is used to store keys on IoT devices;

FIG. 12A illustrates one embodiment in which IoT devices are registeredusing barcodes or QR codes;

FIG. 12B illustrates one embodiment in which pairing is performed usingbarcodes or QR codes;

FIG. 13 illustrates one embodiment of a method for programming a SIMusing an IoT hub;

FIG. 14 illustrates one embodiment of a method for registering an IoTdevice with an IoT hub and IoT service; and

FIG. 15 illustrates one embodiment of a method for encrypting data to betransmitted to an IoT device;

FIGS. 16A-B illustrate different embodiments of the invention forencrypting data between an IoT service and an IoT device;

FIG. 17 illustrates embodiments of the invention for performing a securekey exchange, generating a common secret, and using the secret togenerate a key stream;

FIG. 18 illustrates a packet structure in accordance with one embodimentof the invention;

FIG. 19 illustrates techniques employed in one embodiment for writingand reading data to/from an IoT device without formally pairing with theIoT device;

FIG. 20 illustrates an exemplary set of command packets employed in oneembodiment of the invention;

FIG. 21 illustrates an exemplary sequence of transactions using commandpackets;

FIG. 22 illustrates a method in accordance with one embodiment of theinvention;

FIGS. 23A-C illustrate a method for secure pairing in accordance withone embodiment of the invention;

FIG. 24 illustrates one embodiment of the invention for adjusting anadvertising interval to identify a data transmission condition;

FIG. 25 illustrates a method in accordance with one embodiment of theinvention;

FIGS. 26A-C illustrate the operation of one embodiment in which multipleIoT hubs attempt to transmit data/commands to an IoT device;

FIG. 27 illustrates a method in accordance with one embodiment of theinvention;

FIG. 28 illustrates one embodiment of a system for secure IoT deviceprovisioning;

FIG. 29 illustrates a method in accordance with one embodiment of theinvention;

FIG. 30 one embodiment of a system for performing flow control for aplurality of IoT devices;

FIG. 31 illustrates a method in accordance with one embodiment of theinvention; and

FIG. 32 illustrates one embodiment of a system for managing applicationattributes, system attributes, and priority notification attributes;

FIG. 33 illustrates an example of an integrated development tool fordesigning IoT device program code using attributes;

FIG. 34 illustrates a method in accordance with one embodiment of theinvention;

FIG. 35 illustrates one embodiment for designing using virtual devices;

FIGS. 36A-H illustrate different embodiments of a graphical userinterface for designing and reviewing results;

FIGS. 37A-B illustrate a method in accordance with one embodiment of theinvention;

FIG. 38 illustrates one embodiment which includes configurationattributes;

FIG. 39 illustrates one embodiment in which attributes are configuredwith binding attributes;

FIG. 40 illustrates one embodiment in which attributes are configuredwith grouping attributes;

FIG. 41 illustrates one embodiment of an IoT device with executableprogram code for processing the attributes;

FIG. 42 illustrates one embodiment of development application withattribute validator; and

FIGS. 43A-C illustrate different graphical user interface features forworking with configuration attributes, binding attributes, and groupingattributes.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the embodiments of the invention described below. Itwill be apparent, however, to one skilled in the art that theembodiments of the invention may be practiced without some of thesespecific details. In other instances, well-known structures and devicesare shown in block diagram form to avoid obscuring the underlyingprinciples of the embodiments of the invention.

One embodiment of the invention comprises an Internet of Things (IoT)platform which may be utilized by developers to design and build new IoTdevices and applications. In particular, one embodiment includes a basehardware/software platform for IoT devices including a predefinednetworking protocol stack and an IoT hub through which the IoT devicesare coupled to the Internet. In addition, one embodiment includes an IoTservice through which the IoT hubs and connected IoT devices may beaccessed and managed as described below. In addition, one embodiment ofthe IoT platform includes an IoT app or Web application (e.g., executedon a client device) to access and configured the IoT service, hub andconnected devices. Existing online retailers and other Website operatorsmay leverage the IoT platform described herein to readily provide uniqueIoT functionality to existing user bases.

FIG. 1A illustrates an overview of an architectural platform on whichembodiments of the invention may be implemented. In particular, theillustrated embodiment includes a plurality of IoT devices 101-105communicatively coupled over local communication channels 130 to acentral IoT hub 110 which is itself communicatively coupled to an IoTservice 120 over the Internet 220. Each of the IoT devices 101-105 mayinitially be paired to the IoT hub 110 (e.g., using the pairingtechniques described below) in order to enable each of the localcommunication channels 130. In one embodiment, the IoT service 120includes an end user database 122 for maintaining user accountinformation and data collected from each user's IoT devices. Forexample, if the IoT devices include sensors (e.g., temperature sensors,accelerometers, heat sensors, motion detectore, etc), the database 122may be continually updated to store the data collected by the IoTdevices 101-105. The data stored in the database 122 may then be madeaccessible to the end user via the IoT app or browser installed on theuser's device 135 (or via a desktop or other client computer system) andto web clients (e.g., such as websites 130 subscribing to the IoTservice 120).

The IoT devices 101-105 may be equipped with various types of sensors tocollect information about themselves and their surroundings and providethe collected information to the IoT service 120, user devices 135and/or external Websites 130 via the IoT hub 110. Some of the IoTdevices 101-105 may perform a specified function in response to controlcommands sent through the IoT hub 110. Various specific examples ofinformation collected by the IoT devices 101-105 and control commandsare provided below. In one embodiment described below, the IoT device101 is a user input device designed to record user selections and sendthe user selections to the IoT service 120 and/or Website.

In one embodiment, the IoT hub 110 includes a cellular radio toestablish a connection to the Internet 220 via a cellular service 115such as a 4G (e.g., Mobile WiMAX, LTE) or 5G cellular data service.Alternatively, or in addition, the IoT hub 110 may include a WiFi radioto establish a WiFi connection through a WiFi access point or router 116which couples the IoT hub 110 to the Internet (e.g., via an InternetService Provider providing Internet service to the end user). Of course,it should be noted that the underlying principles of the invention arenot limited to any particular type of communication channel or protocol.

In one embodiment, the IoT devices 101-105 are ultra low-power devicescapable of operating for extended periods of time on battery power(e.g., years). To conserve power, the local communication channels 130may be implemented using a low-power wireless communication technologysuch as Bluetooth Low Energy (LE). In this embodiment, each of the IoTdevices 101-105 and the IoT hub 110 are equipped with Bluetooth LEradios and protocol stacks.

As mentioned, in one embodiment, the IoT platform includes an IoT app orWeb application executed on user devices 135 to allow users to accessand configure the connected IoT devices 101-105, IoT hub 110, and/or IoTservice 120. In one embodiment, the app or web application may bedesigned by the operator of a Website 130 to provide IoT functionalityto its user base. As illustrated, the Website may maintain a userdatabase 131 containing account records related to each user.

FIG. 1B illustrates additional connection options for a plurality of IoThubs 110-111, 190 In this embodiment a single user may have multiplehubs 110-111 installed onsite at a single user premises 180 (e.g., theuser's home or business). This may be done, for example, to extend thewireless range needed to connect all of the IoT devices 101-105. Asindicated, if a user has multiple hubs 110, 111 they may be connectedvia a local communication channel (e.g., Wifi, Ethernet, Power LineNetworking, etc). In one embodiment, each of the hubs 110-111 mayestablish a direct connection to the IoT service 120 through a cellular115 or WiFi 116 connection (not explicitly shown in FIG. 1B).Alternatively, or in addition, one of the IoT hubs such as IoT hub 110may act as a “master” hub which provides connectivity and/or localservices to all of the other IoT hubs on the user premises 180, such asIoT hub 111 (as indicated by the dotted line connecting IoT hub 110 andIoT hub 111). For example, the master IoT hub 110 may be the only IoThub to establish a direct connection to the IoT service 120. In oneembodiment, only the “master” IoT hub 110 is equipped with a cellularcommunication interface to establish the connection to the IoT service120. As such, all communication between the IoT service 120 and theother IoT hubs 111 will flow through the master IoT hub 110. In thisrole, the master IoT hub 110 may be provided with additional programcode to perform filtering operations on the data exchanged between theother IoT hubs 111 and IoT service 120 (e.g., servicing some datarequests locally when possible).

Regardless of how the IoT hubs 110-111 are connected, in one embodiment,the IoT service 120 will logically associate the hubs with the user andcombine all of the attached IoT devices 101-105 under a singlecomprehensive user interface, accessible via a user device with theinstalled app 135 (and/or a browser-based interface).

In this embodiment, the master IoT hub 110 and one or more slave IoThubs 111 may connect over a local network which may be a WiFi network116, an Ethernet network, and/or a using power-line communications (PLC)networking (e.g., where all or portions of the network are run throughthe user's power lines). In addition, to the IoT hubs 110-111, each ofthe IoT devices 101-105 may be interconnected with the IoT hubs 110-111using any type of local network channel such as WiFi, Ethernet, PLC, orBluetooth LE, to name a few.

FIG. 1B also shows an IoT hub 190 installed at a second user premises181. A virtually unlimited number of such IoT hubs 190 may be installedand configured to collect data from IoT devices 191-192 at user premisesaround the world. In one embodiment, the two user premises 180-181 maybe configured for the same user. For example, one user premises 180 maybe the user's primary home and the other user premises 181 may be theuser's vacation home. In such a case, the IoT service 120 will logicallyassociate the IoT hubs 110-111, 190 with the user and combine all of theattached IoT devices 101-105, 191-192 under a single comprehensive userinterface, accessible via a user device with the installed app 135(and/or a browser-based interface).

As illustrated in FIG. 2, an exemplary embodiment of an IoT device 101includes a memory 210 for storing program code and data 201-203 and alow power microcontroller 200 for executing the program code andprocessing the data. The memory 210 may be a volatile memory such asdynamic random access memory (DRAM) or may be a non-volatile memory suchas Flash memory. In one embodiment, a non-volatile memory may be usedfor persistent storage and a volatile memory may be used for executionof the program code and data at runtime. Moreover, the memory 210 may beintegrated within the low power microcontroller 200 or may be coupled tothe low power microcontroller 200 via a bus or communication fabric. Theunderlying principles of the invention are not limited to any particularimplementation of the memory 210.

As illustrated, the program code may include application program code203 defining an application-specific set of functions to be performed bythe IoT device 201 and library code 202 comprising a set of predefinedbuilding blocks which may be utilized by the application developer ofthe IoT device 101. In one embodiment, the library code 202 comprises aset of basic functions required to implement an IoT device such as acommunication protocol stack 201 for enabling communication between eachIoT device 101 and the IoT hub 110. As mentioned, in one embodiment, thecommunication protocol stack 201 comprises a Bluetooth LE protocolstack. In this embodiment, Bluetooth LE radio and antenna 207 may beintegrated within the low power microcontroller 200. However, theunderlying principles of the invention are not limited to any particularcommunication protocol.

The particular embodiment shown in FIG. 2 also includes a plurality ofinput devices or sensors 210 to receive user input and provide the userinput to the low power microcontroller, which processes the user inputin accordance with the application code 203 and library code 202. In oneembodiment, each of the input devices include an LED 209 to providefeedback to the end user.

In addition, the illustrated embodiment includes a battery 208 forsupplying power to the low power microcontroller. In one embodiment, anon-chargeable coin cell battery is used. However, in an alternateembodiment, an integrated rechargeable battery may be used (e.g.,rechargeable by connecting the IoT device to an AC power supply (notshown)).

A speaker 205 is also provided for generating audio. In one embodiment,the low power microcontroller 299 includes audio decoding logic fordecoding a compressed audio stream (e.g., such as an MPEG-4/AdvancedAudio Coding (AAC) stream) to generate audio on the speaker 205.Alternatively, the low power microcontroller 200 and/or the applicationcode/data 203 may include digitally sampled snippets of audio to provideverbal feedback to the end user as the user enters selections via theinput devices 210.

In one embodiment, one or more other/alternate I/O devices or sensors250 may be included on the IoT device 101 based on the particularapplication for which the IoT device 101 is designed. For example, anenvironmental sensor may be included to measure temperature, pressure,humidity, etc. A security sensor and/or door lock opener may be includedif the IoT device is used as a security device. Of course, theseexamples are provided merely for the purposes of illustration. Theunderlying principles of the invention are not limited to any particulartype of IoT device. In fact, given the highly programmable nature of thelow power microcontroller 200 equipped with the library code 202, anapplication developer may readily develop new application code 203 andnew I/O devices 250 to interface with the low power microcontroller forvirtually any type of IoT application.

In one embodiment, the low power microcontroller 200 also includes asecure key store for storing encryption keys for encryptingcommunications and/or generating signatures. Alternatively, the keys maybe secured in a subscriber identify module (SIM).

A wakeup receiver 207 is included in one embodiment to wake the IoTdevice from an ultra low power state in which it is consuming virtuallyno power. In one embodiment, the wakeup receiver 207 is configured tocause the IoT device 101 to exit this low power state in response to awakeup signal received from a wakeup transmitter 307 configured on theIoT hub 110 as shown in FIG. 3. In particular, in one embodiment, thetransmitter 307 and receiver 207 together form an electrical resonanttransformer circuit such as a Tesla coil. In operation, energy istransmitted via radio frequency signals from the transmitter 307 to thereceiver 207 when the hub 110 needs to wake the IoT device 101 from avery low power state. Because of the energy transfer, the IoT device 101may be configured to consume virtually no power when it is in its lowpower state because it does not need to continually “listen” for asignal from the hub (as is the case with network protocols which allowdevices to be awakened via a network signal). Rather, themicrocontroller 200 of the IoT device 101 may be configured to wake upafter being effectively powered down by using the energy electricallytransmitted from the transmitter 307 to the receiver 207.

As illustrated in FIG. 3, the IoT hub 110 also includes a memory 317 forstoring program code and data 305 and hardware logic 301 such as amicrocontroller for executing the program code and processing the data.A wide area network (WAN) interface 302 and antenna 310 couple the IoThub 110 to the cellular service 115. Alternatively, as mentioned above,the IoT hub 110 may also include a local network interface (not shown)such as a WiFi interface (and WiFi antenna) or Ethernet interface forestablishing a local area network communication channel. In oneembodiment, the hardware logic 301 also includes a secure key store forstoring encryption keys for encrypting communications andgenerating/verifying signatures. Alternatively, the keys may be securedin a subscriber identify module (SIM).

A local communication interface 303 and antenna 311 establishes localcommunication channels with each of the IoT devices 101-105. Asmentioned above, in one embodiment, the local communication interface303/antenna 311 implements the Bluetooth LE standard. However, theunderlying principles of the invention are not limited to any particularprotocols for establishing the local communication channels with the IoTdevices 101-105. Although illustrated as separate units in FIG. 3, theWAN interface 302 and/or local communication interface 303 may beembedded within the same chip as the hardware logic 301.

In one embodiment, the program code and data includes a communicationprotocol stack 308 which may include separate stacks for communicatingover the local communication interface 303 and the WAN interface 302. Inaddition, device pairing program code and data 306 may be stored in thememory to allow the IoT hub to pair with new IoT devices. In oneembodiment, each new IoT device 101-105 is assigned a unique code whichis communicated to the IoT hub 110 during the pairing process. Forexample, the unique code may be embedded in a barcode on the IoT deviceand may be read by the barcode reader 106 or may be communicated overthe local communication channel 130. In an alternate embodiment, theunique ID code is embedded magnetically on the IoT device and the IoThub has a magnetic sensor such as an radio frequency ID (RFID) or nearfield communication (NFC) sensor to detect the code when the IoT device101 is moved within a few inches of the IoT hub 110.

In one embodiment, once the unique ID has been communicated, the IoT hub110 may verify the unique ID by querying a local database (not shown),performing a hash to verify that the code is acceptable, and/orcommunicating with the IoT service 120, user device 135 and/or Website130 to validate the ID code. Once validated, in one embodiment, the IoThub 110 pairs the IoT device 101 and stores the pairing data in memory317 (which, as mentioned, may include non-volatile memory). Once pairingis complete, the IoT hub 110 may connect with the IoT device 101 toperform the various IoT functions described herein.

In one embodiment, the organization running the IoT service 120 mayprovide the IoT hub 110 and a basic hardware/software platform to allowdevelopers to easily design new IoT services. In particular, in additionto the IoT hub 110, developers may be provided with a softwaredevelopment kit (SDK) to update the program code and data 305 executedwithin the hub 110. In addition, for IoT devices 101, the SDK mayinclude an extensive set of library code 202 designed for the base IoThardware (e.g., the low power microcontroller 200 and other componentsshown in FIG. 2) to facilitate the design of various different types ofapplications 101. In one embodiment, the SDK includes a graphical designinterface in which the developer needs only to specify input and outputsfor the IoT device. All of the networking code, including thecommunication stack 201 that allows the IoT device 101 to connect to thehub 110 and the service 120, is already in place for the developer. Inaddition, in one embodiment, the SDK also includes a library code baseto facilitate the design of apps for mobile devices (e.g., iPhone andAndroid devices).

In one embodiment, the IoT hub 110 manages a continuous bi-directionalstream of data between the IoT devices 101-105 and the IoT service 120.In circumstances where updates to/from the IoT devices 101-105 arerequired in real time (e.g., where a user needs to view the currentstatus of security devices or environmental readings), the IoT hub maymaintain an open TCP socket to provide regular updates to the userdevice 135 and/or external Websites 130. The specific networkingprotocol used to provide updates may be tweaked based on the needs ofthe underlying application. For example, in some cases, where may notmake sense to have a continuous bi-directional stream, a simplerequest/response protocol may be used to gather information when needed.

In one embodiment, both the IoT hub 110 and the IoT devices 101-105 areautomatically upgradeable over the network. In particular, when a newupdate is available for the IoT hub 110 it may automatically downloadand install the update from the IoT service 120. It may first copy theupdated code into a local memory, run and verify the update beforeswapping out the older program code. Similarly, when updates areavailable for each of the IoT devices 101-105, they may initially bedownloaded by the IoT hub 110 and pushed out to each of the IoT devices101-105. Each IoT device 101-105 may then apply the update in a similarmanner as described above for the IoT hub and report back the results ofthe update to the IoT hub 110. If the update is successful, then the IoThub 110 may delete the update from its memory and record the latestversion of code installed on each IoT device (e.g., so that it maycontinue to check for new updates for each IoT device).

In one embodiment, the IoT hub 110 is powered via A/C power. Inparticular, the IoT hub 110 may include a power unit 390 with atransformer for transforming A/C voltage supplied via an A/C power cordto a lower DC voltage.

FIG. 4A illustrates one embodiment of the invention for performinguniversal remote control operations using the IoT system. In particular,in this embodiment, a set of IoT devices 101-103 are equipped withinfrared (IR) and/or radio frequency (RF) blasters 401-403,respectively, for transmitting remote control codes to control variousdifferent types of electronics equipment including airconditioners/heaters 430, lighting systems 431, and audiovisualequipment 432 (to name just a few). In the embodiment shown in FIG. 4A,the IoT devices 101-103 are also equipped with sensors 404-406,respectively, for detecting the operation of the devices which theycontrol, as described below.

For example, sensor 404 in IoT device 101 may be a temperature and/orhumidity sensor for sensing the current temperature/humidity andresponsively controlling the air conditioner/heater 430 based on acurrent desired temperature. In this embodiment, the airconditioner/heater 430 is one which is designed to be controlled via aremote control device (typically a remote control which itself has atemperature sensor embedded therein). In one embodiment, the userprovides the desired temperature to the IoT hub 110 via an app orbrowser installed on a user device 135. Control logic 412 executed onthe IoT hub 110 receives the current temperature/humidity data from thesensor 404 and responsively transmits commands to the IoT device 101 tocontrol the IR/RF blaster 401 in accordance with the desiredtemperature/humidity. For example, if the temperature is below thedesired temperature, then the control logic 412 may transmit a commandto the air conditioner/heater via the IR/RF blaster 401 to increase thetemperature (e.g., either by turning off the air conditioner or turningon the heater). The command may include the necessary remote controlcode stored in a database 413 on the IoT hub 110. Alternatively, or inaddition, the IoT service 421 may implement control logic 421 to controlthe electronics equipment 430-432 based on specified user preferencesand stored control codes 422.

IoT device 102 in the illustrated example is used to control lighting431. In particular, sensor 405 in IoT device 102 may photosensor orphotodetector configured to detect the current brightness of the lightbeing produced by a light fixture 431 (or other lighting apparatus). Theuser may specify a desired lighting level (including an indication of ONor OFF) to the IoT hub 110 via the user device 135. In response, thecontrol logic 412 will transmit commands to the IR/RF blaster 402 tocontrol the current brightness level of the lights 431 (e.g., increasingthe lighting if the current brightness is too low or decreasing thelighting if the current brightness is too high; or simply turning thelights ON or OFF).

IoT device 103 in the illustrated example is configured to controlaudiovisual equipment 432 (e.g., a television, A/V receiver,cable/satellite receiver, AppleTV™, etc). Sensor 406 in IoT device 103may be an audio sensor (e.g., a microphone and associated logic) fordetecting a current ambient volume level and/or a photosensor to detectwhether a television is on or off based on the light generated by thetelevision (e.g., by measuring the light within a specified spectrum).Alternatively, sensor 406 may include a temperature sensor connected tothe audiovisual equipment to detect whether the audio equipment is on oroff based on the detected temperature. Once again, in response to userinput via the user device 135, the control logic 412 may transmitcommands to the audiovisual equipment via the IR blaster 403 of the IoTdevice 103.

It should be noted that the foregoing are merely illustrative examplesof one embodiment of the invention. The underlying principles of theinvention are not limited to any particular type of sensors or equipmentto be controlled by IoT devices.

In an embodiment in which the IoT devices 101-103 are coupled to the IoThub 110 via a Bluetooth LE connection, the sensor data and commands aresent over the Bluetooth LE channel. However, the underlying principlesof the invention are not limited to Bluetooth LE or any othercommunication standard.

In one embodiment, the control codes required to control each of thepieces of electronics equipment are stored in a database 413 on the IoThub 110 and/or a database 422 on the IoT service 120. As illustrated inFIG. 4B, the control codes may be provided to the IoT hub 110 from amaster database of control codes 422 for different pieces of equipmentmaintained on the IoT service 120. The end user may specify the types ofelectronic (or other) equipment to be controlled via the app or browserexecuted on the user device 135 and, in response, a remote control codelearning module 491 on the IoT hub may retrieve the required IR/RF codesfrom the remote control code database 492 on the IoT service 120 (e.g.,identifying each piece of electronic equipment with a unique ID).

In addition, in one embodiment, the IoT hub 110 is equipped with anIR/RF interface 490 to allow the remote control code learning module 491to “learn” new remote control codes directly from the original remotecontrol 495 provided with the electronic equipment. For example, ifcontrol codes for the original remote control provided with the airconditioner 430 is not included in the remote control database, the usermay interact with the IoT hub 110 via the app/browser on the user device135 to teach the IoT hub 110 the various control codes generated by theoriginal remote control (e.g., increase temperature, decreasetemperature, etc). Once the remote control codes are learned they may bestored in the control code database 413 on the IoT hub 110 and/or sentback to the IoT service 120 to be included in the central remote controlcode database 492 (and subsequently used by other users with the sameair conditioner unit 430).

In one embodiment, each of the IoT devices 101-103 have an extremelysmall form factor and may be affixed on or near their respectiveelectronics equipment 430-432 using double-sided tape, a small nail, amagnetic attachment, etc. For control of a piece of equipment such asthe air conditioner 430, it would be desirable to place the IoT device101 sufficiently far away so that the sensor 404 can accurately measurethe ambient temperature in the home (e.g., placing the IoT devicedirectly on the air conditioner would result in a temperaturemeasurement which would be too low when the air conditioner was runningor too high when the heater was running). In contrast, the IoT device102 used for controlling lighting may be placed on or near the lightingfixture 431 for the sensor 405 to detect the current lighting level.

In addition to providing general control functions as described, oneembodiment of the IoT hub 110 and/or IoT service 120 transmitsnotifications to the end user related to the current status of eachpiece of electronics equipment. The notifications, which may be textmessages and/or app-specific notifications, may then be displayed on thedisplay of the user's mobile device 135. For example, if the user's airconditioner has been on for an extended period of time but thetemperature has not changed, the IoT hub 110 and/or IoT service 120 maysend the user a notification that the air conditioner is not functioningproperly. If the user is not home (which may be detected via motionsensors or based on the user's current detected location), and thesensors 406 indicate that audiovisual equipment 430 is on or sensors 405indicate that the lights are on, then a notification may be sent to theuser, asking if the user would like to turn off the audiovisualequipment 432 and/or lights 431. The same type of notification may besent for any equipment type.

Once the user receives a notification, he/she may remotely control theelectronics equipment 430-432 via the app or browser on the user device135. In one embodiment, the user device 135 is a touchscreen device andthe app or browser displays an image of a remote control withuser-selectable buttons for controlling the equipment 430-432. Uponreceiving a notification, the user may open the graphical remote controland turn off or adjust the various different pieces of equipment. Ifconnected via the IoT service 120, the user's selections may beforwarded from the IoT service 120 to the IoT hub 110 which will thencontrol the equipment via the control logic 412. Alternatively, the userinput may be sent directly to the IoT hub 110 from the user device 135.

In one embodiment, the user may program the control logic 412 on the IoThub 110 to perform various automatic control functions with respect tothe electronics equipment 430-432. In addition to maintaining a desiredtemperature, brightness level, and volume level as described above, thecontrol logic 412 may automatically turn off the electronics equipmentif certain conditions are detected. For example, if the control logic412 detects that the user is not home and that the air conditioner isnot functioning, it may automatically turn off the air conditioner.Similarly, if the user is not home, and the sensors 406 indicate thataudiovisual equipment 430 is on or sensors 405 indicate that the lightsare on, then the control logic 412 may automatically transmit commandsvia the IR/RF blasters 403 and 402, to turn off the audiovisualequipment and lights, respectively.

FIG. 5 illustrates additional embodiments of IoT devices 104-105equipped with sensors 503-504 for monitoring electronic equipment530-531. In particular, the IoT device 104 of this embodiment includes atemperature sensor 503 which may be placed on or near a stove 530 todetect when the stove has been left on. In one embodiment, the IoTdevice 104 transmits the current temperature measured by the temperaturesensor 503 to the IoT hub 110 and/or the IoT service 120. If the stoveis detected to be on for more than a threshold time period (e.g., basedon the measured temperature), then control logic 512 may transmit anotification to the end user's device 135 informing the user that thestove 530 is on. In addition, in one embodiment, the IoT device 104 mayinclude a control module 501 to turn off the stove, either in responseto receiving an instruction from the user or automatically (if thecontrol logic 512 is programmed to do so by the user). In oneembodiment, the control logic 501 comprises a switch to cut offelectricity or gas to the stove 530. However, in other embodiments, thecontrol logic 501 may be integrated within the stove itself.

FIG. 5 also illustrates an IoT device 105 with a motion sensor 504 fordetecting the motion of certain types of electronics equipment such as awasher and/or dryer. Another sensor that may be used is an audio sensor(e.g., microphone and logic) for detecting an ambient volume level. Aswith the other embodiments described above, this embodiment may transmitnotifications to the end user if certain specified conditions are met(e.g., if motion is detected for an extended period of time, indicatingthat the washer/dryer are not turning off). Although not shown in FIG.5, IoT device 105 may also be equipped with a control module to turn offthe washer/dryer 531 (e.g., by switching off electric/gas),automatically, and/or in response to user input.

In one embodiment, a first IoT device with control logic and a switchmay be configured to turn off all power in the user's home and a secondIoT device with control logic and a switch may be configured to turn offall gas in the user's home. IoT devices with sensors may then bepositioned on or near electronic or gas-powered equipment in the user'shome. If the user is notified that a particular piece of equipment hasbeen left on (e.g., the stove 530), the user may then send a command toturn off all electricity or gas in the home to prevent damage.Alternatively, the control logic 512 in the IoT hub 110 and/or the IoTservice 120 may be configured to automatically turn off electricity orgas in such situations.

In one embodiment, the IoT hub 110 and IoT service 120 communicate atperiodic intervals. If the IoT service 120 detects that the connectionto the IoT hub 110 has been lost (e.g., by failing to receive a requestor response from the IoT hub for a specified duration), it willcommunicate this information to the end user's device 135 (e.g., bysending a text message or app-specific notification).

Apparatus and Method for Communicating Data Through an IntermediaryDevice

As mentioned above, because the wireless technologies used tointerconnect IoT devices such as Bluetooth LE are generally short rangetechnologies, if the hub for an IoT implementation is outside the rangeof an IoT device, the IoT device will not be able to transmit data tothe IoT hub (and vice versa).

To address this deficiency, one embodiment of the invention provides amechanism for an IoT device which is outside of the wireless range ofthe IoT hub to periodically connect with one or more mobile devices whenthe mobile devices are within range. Once connected, the IoT device cantransmit any data which needs to be provided to the IoT hub to themobile device which then forwards the data to the IoT hub.

As illustrated in FIG. 6 one embodiment includes an IoT hub 110, an IoTdevice 601 which is out of range of the IoT hub 110 and a mobile device611. The out of range IoT device 601 may include any form of IoT devicecapable of collecting and communicating data. For example, the IoTdevice 601 may comprise a data collection device configured within arefrigerator to monitor the food items available in the refrigerator,the users who consume the food items, and the current temperature. Ofcourse, the underlying principles of the invention are not limited toany particular type of IoT device. The techniques described herein maybe implemented using any type of IoT device including those used tocollect and transmit data for smart meters, stoves, washers, dryers,lighting systems, HVAC systems, and audiovisual equipment, to name justa few.

Moreover, the mobile device In operation, the IoT device 611 illustratedin FIG. 6 may be any form of mobile device capable of communicating andstoring data. For example, in one embodiment, the mobile device 611 is asmartphone with an app installed thereon to facilitate the techniquesdescribed herein. In another embodiment, the mobile device 611 comprisesa wearable device such as a communication token affixed to a neckless orbracelet, a smartwatch or a fitness device. The wearable token may beparticularly useful for elderly users or other users who do not own asmartphone device.

In operation, the out of range IoT device 601 may periodically orcontinually check for connectivity with a mobile device 611. Uponestablishing a connection (e.g., as the result of the user moving withinthe vicinity of the refrigerator) any collected data 605 on the IoTdevice 601 is automatically transmitted to a temporary data repository615 on the mobile device 611. In one embodiment, the IoT device 601 andmobile device 611 establish a local wireless communication channel usinga low power wireless standard such as BTLE. In such a case, the mobiledevice 611 may initially be paired with the IoT device 601 using knownpairing techniques.

One the data has been transferred to the temporary data repository, themobile device 611 will transmit the data once communication isestablished with the IoT hub 110 (e.g., when the user walks within therange of the IoT hub 110). The IoT hub may then store the data in acentral data repository 413 and/or send the data over the Internet toone or more services and/or other user devices. In one embodiment, themobile device 611 may use a different type of communication channel toprovide the data to the IoT hub 110 (potentially a higher powercommunication channel such as WiFi).

The out of range IoT device 601, the mobile device 611, and the IoT hubmay all be configured with program code and/or logic to implement thetechniques described herein. As illustrated in FIG. 7, for example, theIoT device 601 may be configured with intermediary connection logicand/or application, the mobile device 611 may be configured with anintermediary connection logic/application, and the IoT hub 110 may beconfigured with an intermediary connection logic/application 721 toperform the operations described herein. The intermediary connectionlogic/application on each device may be implemented in hardware,software, or any combination thereof. In one embodiment, theintermediary connection logic/application 701 of the IoT device 601searches and establishes a connection with the intermediary connectionlogic/application 711 on the mobile device (which may be implemented asa device app) to transfer the data to the temporary data repository 615.The intermediary connection logic/application 701 on the mobile device611 then forwards the data to the intermediary connectionlogic/application on the IoT hub, which stores the data in the centraldata repository 413.

As illustrated in FIG. 7, the intermediary connection logic/applications701, 711, 721, on each device may be configured based on the applicationat hand. For example, for a refrigerator, the connectionlogic/application 701 may only need to transmit a few packets on aperiodic basis. For other applications (e.g., temperature sensors), theconnection logic/application 701 may need to transmit more frequentupdates.

Rather than a mobile device 611, in one embodiment, the IoT device 601may be configured to establish a wireless connection with one or moreintermediary IoT devices, which are located within range of the IoT hub110. In this embodiment, any IoT devices 601 out of range of the IoT hubmay be linked to the hub by forming a “chain” using other IoT devices.

In addition, while only a single mobile device 611 is illustrated inFIGS. 6-7 for simplicity, in one embodiment, multiple such mobiledevices of different users may be configured to communicate with the IoTdevice 601. Moreover, the same techniques may be implemented formultiple other IoT devices, thereby forming an intermediary device datacollection system across the entire home.

Moreover, in one embodiment, the techniques described herein may be usedto collect various different types of pertinent data. For example, inone embodiment, each time the mobile device 611 connects with the IoTdevice 601, the identity of the user may be included with the collecteddata 605. In this manner, the IoT system may be used to track thebehavior of different users within the home. For example, if used withina refrigerator, the collected data 605 may then include the identify ofeach user who passes by fridge, each user who opens the fridge, and thespecific food items consumed by each user. Different types of data maybe collected from other types of IoT devices. Using this data the systemis able to determine, for example, which user washes clothes, which userwatches TV on a given day, the times at which each user goes to sleepand wakes up, etc. All of this crowd-sourced data may then be compiledwithin the data repository 413 of the IoT hub and/or forwarded to anexternal service or user.

Another beneficial application of the techniques described herein is formonitoring elderly users who may need assistance. For this application,the mobile device 611 may be a very small token worn by the elderly userto collect the information in different rooms of the user's home. Eachtime the user opens the refrigerator, for example, this data will beincluded with the collected data 605 and transferred to the IoT hub 110via the token. The IoT hub may then provide the data to one or moreexternal users (e.g., the children or other individuals who care for theelderly user). If data has not been collected for a specified period oftime (e.g., 12 hours), then this means that the elderly user has notbeen moving around the home and/or has not been opening therefrigerator. The IoT hub 110 or an external service connected to theIoT hub may then transmit an alert notification to these otherindividuals, informing them that they should check on the elderly user.In addition, the collected data 605 may include other pertinentinformation such as the food being consumed by the user and whether atrip to the grocery store is needed, whether and how frequently theelderly user is watching TV, the frequency with which the elderly userwashes clothes, etc.

In another implementation, the if there is a problem with an electronicdevice such as a washer, refrigerator, HVAC system, etc, the collecteddata may include an indication of a part that needs to be replaced. Insuch a case, a notification may be sent to a technician with a requestto fix the problem. The technician may then arrive at the home with theneeded replacement part.

A method in accordance with one embodiment of the invention isillustrated in FIG. 8. The method may be implemented within the contextof the architectures described above, but is not limited to anyparticular architecture.

At 801, an IoT device which is out of range of the IoT hub periodicallycollects data (e.g., opening of the refrigerator door, food items used,etc). At 802 the IoT device periodically or continually checks forconnectivity with a mobile device (e.g., using standard local wirelesstechniques for establishing a connection such as those specified by theBTLE standard). If the connection to the mobile device is established,determined at 802, then at 803, the collected data is transferred to themobile device at 803. At 804, the mobile device transfers the data tothe IoT hub, an external service and/or a user. As mentioned, the mobiledevice may transmit the data immediately if it is already connected(e.g., via a WiFi link).

In addition to collecting data from IoT devices, in one embodiment, thetechniques described herein may be used to update or otherwise providedata to IoT devices. One example is shown in FIG. 9A, which shows an IoThub 110 with program code updates 901 that need to be installed on anIoT device 601 (or a group of such IoT devices). The program codeupdates may include system updates, patches, configuration data and anyother data needed for the IoT device to operate as desired by the user.In one embodiment, the user may specify configuration options for theIoT device 601 via a mobile device or computer which are then stored onthe IoT hub 110 and provided to the IoT device using the techniquesdescribed herein. Specifically, in one embodiment, the intermediaryconnection logic/application 721 on the IoT hub 110 communicates withthe intermediary connection logic/application 711 on the mobile device611 to store the program code updates within a temporary storage 615.When the mobile device 611 enters the range of the IoT device 601, theintermediary connection logic/application 711 on the mobile device 611connects with the intermediary/connection logic/application 701 on theIoT device 601 to provide the program code updates to the device. In oneembodiment, the IoT device 601 may then enter into an automated updateprocess to install the new program code updates and/or data.

A method for updating an IoT device is shown in FIG. 9B. The method maybe implemented within the context of the system architectures describedabove, but is not limited to any particular system architectures.

At 900 new program code or data updates are made available on the IoThub and/or an external service (e.g., coupled to the mobile device overthe Internet). At 901, the mobile device receives and stores the programcode or data updates on behalf of the IoT device. The IoT device and/ormobile device periodically check to determine whether a connection hasbeen established at 902. If a connection is established, determined at903, then at 904 the updates are transferred to the IoT device andinstalled.

Embodiments for Improved Security

In one embodiment, the low power microcontroller 200 of each IoT device101 and the low power logic/microcontroller 301 of the IoT hub 110include a secure key store for storing encryption keys used by theembodiments described below (see, e.g., FIGS. 10-15 and associatedtext). Alternatively, the keys may be secured in a subscriber identifymodule (SIM) as discussed below.

FIG. 10 illustrates a high level architecture which uses public keyinfrastructure (PKI) techniques and/or symmetric key exchange/encryptiontechniques to encrypt communications between the IoT Service 120, theIoT hub 110 and the IoT devices 101-102.

Embodiments which use public/private key pairs will first be described,followed by embodiments which use symmetric key exchange/encryptiontechniques. In particular, in an embodiment which uses PKI, a uniquepublic/private key pair is associated with each IoT device 101-102, eachIoT hub 110 and the IoT service 120. In one embodiment, when a new IoThub 110 is set up, its public key is provided to the IoT service 120 andwhen a new IoT device 101 is set up, it's public key is provided to boththe IoT hub 110 and the IoT service 120. Various techniques for securelyexchanging the public keys between devices are described below. In oneembodiment, all public keys are signed by a master key known to all ofthe receiving devices (i.e., a form of certificate) so that anyreceiving device can verify the validity of the public keys byvalidating the signatures. Thus, these certificates would be exchangedrather than merely exchanging the raw public keys.

As illustrated, in one embodiment, each IoT device 101, 102 includes asecure key storage 1001, 1003, respectively, for security storing eachdevice's private key. Security logic 1002, 1304 then utilizes thesecurely stored private keys to perform the encryption/decryptionoperations described herein. Similarly, the IoT hub 110 includes asecure storage 1011 for storing the IoT hub private key and the publickeys of the IoT devices 101-102 and the IoT service 120; as well assecurity logic 1012 for using the keys to perform encryption/decryptionoperations. Finally, the IoT service 120 may include a secure storage1021 for security storing its own private key, the public keys ofvarious IoT devices and IoT hubs, and a security logic 1013 for usingthe keys to encrypt/decrypt communication with IoT hubs and devices. Inone embodiment, when the IoT hub 110 receives a public key certificatefrom an IoT device it can verify it (e.g., by validating the signatureusing the master key as described above), and then extract the publickey from within it and store that public key in it's secure key store1011.

By way of example, in one embodiment, when the IoT service 120 needs totransmit a command or data to an IoT device 101 (e.g., a command tounlock a door, a request to read a sensor, data to beprocessed/displayed by the IoT device, etc) the security logic 1013encrypts the data/command using the public key of the IoT device 101 togenerate an encrypted IoT device packet. In one embodiment, it thenencrypts the IoT device packet using the public key of the IoT hub 110to generate an IoT hub packet and transmits the IoT hub packet to theIoT hub 110. In one embodiment, the service 120 signs the encryptedmessage with it's private key or the master key mentioned above so thatthe device 101 can verify it is receiving an unaltered message from atrusted source. The device 101 may then validate the signature using thepublic key corresponding to the private key and/or the master key. Asmentioned above, symmetric key exchange/encryption techniques may beused instead of public/private key encryption. In these embodiments,rather than privately storing one key and providing a correspondingpublic key to other devices, the devices may each be provided with acopy of the same symmetric key to be used for encryption and to validatesignatures. One example of a symmetric key algorithm is the AdvancedEncryption Standard (AES), although the underlying principles of theinvention are not limited to any type of specific symmetric keys.

Using a symmetric key implementation, each device 101 enters into asecure key exchange protocol to exchange a symmetric key with the IoThub 110. A secure key provisioning protocol such as the DynamicSymmetric Key Provisioning Protocol (DSKPP) may be used to exchange thekeys over a secure communication channel (see, e.g., Request forComments (RFC) 6063). However, the underlying principles of theinvention are not limited to any particular key provisioning protocol.

Once the symmetric keys have been exchanged, they may be used by eachdevice 101 and the IoT hub 110 to encrypt communications. Similarly, theIoT hub 110 and IoT service 120 may perform a secure symmetric keyexchange and then use the exchanged symmetric keys to encryptcommunications. In one embodiment a new symmetric key is exchangedperiodically between the devices 101 and the hub 110 and between the hub110 and the IoT service 120. In one embodiment, a new symmetric key isexchanged with each new communication session between the devices 101,the hub 110, and the service 120 (e.g., a new key is generated andsecurely exchanged for each communication session). In one embodiment,if the security module 1012 in the IoT hub is trusted, the service 120could negotiate a session key with the hub security module 1312 and thenthe security module 1012 would negotiate a session key with each device120. Messages from the service 120 would then be decrypted and verifiedin the hub security module 1012 before being re-encrypted fortransmission to the device 101.

In one embodiment, to prevent a compromise on the hub security module1012 a one-time (permanent) installation key may be negotiated betweenthe device 101 and service 120 at installation time. When sending amessage to a device 101 the service 120 could first encrypt/MAC withthis device installation key, then encrypt/MAC that with the hub'ssession key. The hub 110 would then verify and extract the encrypteddevice blob and send that to the device.

In one embodiment of the invention, a counter mechanism is implementedto prevent replay attacks. For example, each successive communicationfrom the device 101 to the hub 110 (or vice versa) may be assigned acontinually increasing counter value. Both the hub 110 and device 101will track this value and verify that the value is correct in eachsuccessive communication between the devices. The same techniques may beimplemented between the hub 110 and the service 120. Using a counter inthis manner would make it more difficult to spoof the communicationbetween each of the devices (because the counter value would beincorrect). However, even without this a shared installation key betweenthe service and device would prevent network (hub) wide attacks to alldevices.

In one embodiment, when using public/private key encryption, the IoT hub110 uses its private key to decrypt the IoT hub packet and generate theencrypted IoT device packet, which it transmits to the associated IoTdevice 101. The IoT device 101 then uses its private key to decrypt theIoT device packet to generate the command/data originated from the IoTservice 120. It may then process the data and/or execute the command.Using symmetric encryption, each device would encrypt and decrypt withthe shared symmetric key. If either case, each transmitting device mayalso sign the message with it's private key so that the receiving devicecan verify it's authenticity.

A different set of keys may be used to encrypt communication from theIoT device 101 to the IoT hub 110 and to the IoT service 120. Forexample, using a public/private key arrangement, in one embodiment, thesecurity logic 1002 on the IoT device 101 uses the public key of the IoThub 110 to encrypt data packets sent to the IoT hub 110. The securitylogic 1012 on the IoT hub 110 may then decrypt the data packets usingthe IoT hub's private key. Similarly, the security logic 1002 on the IoTdevice 101 and/or the security logic 1012 on the IoT hub 110 may encryptdata packets sent to the IoT service 120 using the public key of the IoTservice 120 (which may then be decrypted by the security logic 1013 onthe IoT service 120 using the service's private key). Using symmetrickeys, the device 101 and hub 110 may share a symmetric key while the huband service 120 may share a different symmetric key.

While certain specific details are set forth above in the descriptionabove, it should be noted that the underlying principles of theinvention may be implemented using various different encryptiontechniques. For example, while some embodiments discussed above useasymmetric public/private key pairs, an alternate embodiment may usesymmetric keys securely exchanged between the various IoT devices101-102, IoT hubs 110, and the IoT service 120. Moreover, in someembodiments, the data/command itself is not encrypted, but a key is usedto generate a signature over the data/command (or other data structure).The recipient may then use its key to validate the signature.

As illustrated in FIG. 11, in one embodiment, the secure key storage oneach IoT device 101 is implemented using a programmable subscriberidentity module (SIM) 1101. In this embodiment, the IoT device 101 mayinitially be provided to the end user with an un-programmed SIM card1101 seated within a SIM interface 1100 on the IoT device 101. In orderto program the SIM with a set of one or more encryption keys, the usertakes the programmable SIM card 1101 out of the SIM interface 500 andinserts it into a SIM programming interface 1102 on the IoT hub 110.Programming logic 1125 on the IoT hub then securely programs the SIMcard 1101 to register/pair the IoT device 101 with the IoT hub 110 andIoT service 120. In one embodiment, a public/private key pair may berandomly generated by the programming logic 1125 and the public key ofthe pair may then be stored in the IoT hub's secure storage device 411while the private key may be stored within the programmable SIM 1101. Inaddition, the programming logic 525 may store the public keys of the IoThub 110, the IoT service 120, and/or any other IoT devices 101 on theSIM card 1401 (to be used by the security logic 1302 on the IoT device101 to encrypt outgoing data). Once the SIM 1101 is programmed, the newIoT device 101 may be provisioned with the IoT Service 120 using the SIMas a secure identifier (e.g., using existing techniques for registeringa device using a SIM). Following provisioning, both the IoT hub 110 andthe IoT service 120 will securely store a copy of the IoT device'spublic key to be used when encrypting communication with the IoT device101.

The techniques described above with respect to FIG. 11 provide enormousflexibility when providing new IoT devices to end users. Rather thanrequiring a user to directly register each SIM with a particular serviceprovider upon sale/purchase (as is currently done), the SIM may beprogrammed directly by the end user via the IoT hub 110 and the resultsof the programming may be securely communicated to the IoT service 120.Consequently, new IoT devices 101 may be sold to end users from onlineor local retailers and later securely provisioned with the IoT service120.

While the registration and encryption techniques are described abovewithin the specific context of a SIM (Subscriber Identity Module), theunderlying principles of the invention are not limited to a “SIM”device. Rather, the underlying principles of the invention may beimplemented using any type of device having secure storage for storing aset of encryption keys. Moreover, while the embodiments above include aremovable SIM device, in one embodiment, the SIM device is not removablebut the IoT device itself may be inserted within the programminginterface 1102 of the IoT hub 110.

In one embodiment, rather than requiring the user to program the SIM (orother device), the SIM is pre-programmed into the IoT device 101, priorto distribution to the end user. In this embodiment, when the user setsup the IoT device 101, various techniques described herein may be usedto securely exchange encryption keys between the IoT hub 110/IoT service120 and the new IoT device 101.

For example, as illustrated in FIG. 12A each IoT device 101 or SIM 401may be packaged with a barcode or QR code 1501 uniquely identifying theIoT device 101 and/or SIM 1001. In one embodiment, the barcode or QRcode 1201 comprises an encoded representation of the public key for theIoT device 101 or SIM 1001. Alternatively, the barcode or QR code 1201may be used by the IoT hub 110 and/or IoT service 120 to identify orgenerate the public key (e.g., used as a pointer to the public key whichis already stored in secure storage). The barcode or QR code 601 may beprinted on a separate card (as shown in FIG. 12A) or may be printeddirectly on the IoT device itself. Regardless of where the barcode isprinted, in one embodiment, the IoT hub 110 is equipped with a barcodereader 206 for reading the barcode and providing the resulting data tothe security logic 1012 on the IoT hub 110 and/or the security logic1013 on the IoT service 120. The security logic 1012 on the IoT hub 110may then store the public key for the IoT device within its secure keystorage 1011 and the security logic 1013 on the IoT service 120 maystore the public key within its secure storage 1021 (to be used forsubsequent encrypted communication).

In one embodiment, the data contained in the barcode or QR code 1201 mayalso be captured via a user device 135 (e.g., such as an iPhone orAndroid device) with an installed IoT app or browser-based appletdesigned by the IoT service provider. Once captured, the barcode datamay be securely communicated to the IoT service 120 over a secureconnection (e.g., such as a secure sockets layer (SSL) connection). Thebarcode data may also be provided from the client device 135 to the IoThub 110 over a secure local connection (e.g., over a local WiFi orBluetooth LE connection).

The security logic 1002 on the IoT device 101 and the security logic1012 on the IoT hub 110 may be implemented using hardware, software,firmware or any combination thereof. For example, in one embodiment, thesecurity logic 1002, 1012 is implemented within the chips used forestablishing the local communication channel 130 between the IoT device101 and the IoT hub 110 (e.g., the Bluetooth LE chip if the localchannel 130 is Bluetooth LE). Regardless of the specific location of thesecurity logic 1002, 1012, in one embodiment, the security logic 1002,1012 is designed to establish a secure execution environment forexecuting certain types of program code. This may be implemented, forexample, by using TrustZone technology (available on some ARMprocessors) and/or Trusted Execution Technology (designed by Intel). Ofcourse, the underlying principles of the invention are not limited toany particular type of secure execution technology.

In one embodiment, the barcode or QR code 1501 may be used to pair eachIoT device 101 with the IoT hub 110. For example, rather than using thestandard wireless pairing process currently used to pair Bluetooth LEdevices, a pairing code embedded within the barcode or QR code 1501 maybe provided to the IoT hub 110 to pair the IoT hub with thecorresponding IoT device.

FIG. 12B illustrates one embodiment in which the barcode reader 206 onthe IoT hub 110 captures the barcode/QR code 1201 associated with theIoT device 101. As mentioned, the barcode/QR code 1201 may be printeddirectly on the IoT device 101 or may be printed on a separate cardprovided with the IoT device 101. In either case, the barcode reader 206reads the pairing code from the barcode/QR code 1201 and provides thepairing code to the local communication module 1280. In one embodiment,the local communication module 1280 is a Bluetooth LE chip andassociated software, although the underlying principles of the inventionare not limited to any particular protocol standard. Once the pairingcode is received, it is stored in a secure storage containing pairingdata 1285 and the IoT device 101 and IoT hub 110 are automaticallypaired. Each time the IoT hub is paired with a new IoT device in thismanner, the pairing data for that pairing is stored within the securestorage 685. In one embodiment, once the local communication module 1280of the IoT hub 110 receives the pairing code, it may use the code as akey to encrypt communications over the local wireless channel with theIoT device 101.

Similarly, on the IoT device 101 side, the local communication module1590 stores pairing data within a local secure storage device 1595indicating the pairing with the IoT hub. The pairing data 1295 mayinclude the pre-programmed pairing code identified in the barcode/QRcode 1201. The pairing data 1295 may also include pairing data receivedfrom the local communication module 1280 on the IoT hub 110 required forestablishing a secure local communication channel (e.g., an additionalkey to encrypt communication with the IoT hub 110).

Thus, the barcode/QR code 1201 may be used to perform local pairing in afar more secure manner than current wireless pairing protocols becausethe pairing code is not transmitted over the air. In addition, in oneembodiment, the same barcode/QR code 1201 used for pairing may be usedto identify encryption keys to build a secure connection from the IoTdevice 101 to the IoT hub 110 and from the IoT hub 110 to the IoTservice 120.

A method for programming a SIM card in accordance with one embodiment ofthe invention is illustrated in FIG. 13. The method may be implementedwithin the system architecture described above, but is not limited toany particular system architecture.

At 1301, a user receives a new IoT device with a blank SIM card and, at1602, the user inserts the blank SIM card into an IoT hub. At 1303, theuser programs the blank SIM card with a set of one or more encryptionkeys. For example, as mentioned above, in one embodiment, the IoT hubmay randomly generate a public/private key pair and store the privatekey on the SIM card and the public key in its local secure storage. Inaddition, at 1304, at least the public key is transmitted to the IoTservice so that it may be used to identify the IoT device and establishencrypted communication with the IoT device. As mentioned above, in oneembodiment, a programmable device other than a “SIM” card may be used toperform the same functions as the SIM card in the method shown in FIG.13.

A method for integrating a new IoT device into a network is illustratedin FIG. 14. The method may be implemented within the system architecturedescribed above, but is not limited to any particular systemarchitecture.

At 1401, a user receives a new IoT device to which an encryption key hasbeen pre-assigned. At 1402, the key is securely provided to the IoT hub.As mentioned above, in one embodiment, this involves reading a barcodeassociated with the IoT device to identify the public key of apublic/private key pair assigned to the device. The barcode may be readdirectly by the IoT hub or captured via a mobile device via an app orbrowser. In an alternate embodiment, a secure communication channel suchas a Bluetooth LE channel, a near field communication (NFC) channel or asecure WiFi channel may be established between the IoT device and theIoT hub to exchange the key. Regardless of how the key is transmitted,once received, it is stored in the secure keystore of the IoT hubdevice. As mentioned above, various secure execution technologies may beused on the IoT hub to store and protect the key such as SecureEnclaves, Trusted Execution Technology (TXT), and/or Trustzone. Inaddition, at 803, the key is securely transmitted to the IoT servicewhich stores the key in its own secure keystore. It may then use the keyto encrypt communication with the IoT device. One again, the exchangemay be implemented using a certificate/signed key. Within the hub 110 itis particularly important to prevent modification/addition/removal ofthe stored keys.

A method for securely communicating commands/data to an IoT device usingpublic/private keys is illustrated in FIG. 15. The method may beimplemented within the system architecture described above, but is notlimited to any particular system architecture.

At 1501, the IoT service encrypts the data/commands using the IoT devicepublic key to create an IoT device packet. It then encrypts the IoTdevice packet using IoT hub's public key to create the IoT hub packet(e.g., creating an IoT hub wrapper around the IoT device packet). At1502, the IoT service transmits the IoT hub packet to the IoT hub. At1503, the IoT hub decrypts the IoT hub packet using the IoT hub'sprivate key to generate the IoT device packet. At 1504 it then transmitsthe IoT device packet to the IoT device which, at 1505, decrypts the IoTdevice packet using the IoT device private key to generate thedata/commands. At 1506, the IoT device processes the data/commands.

In an embodiment which uses symmetric keys, a symmetric key exchange maybe negotiated between each of the devices (e.g., each device and the huband between the hub and the service). Once the key exchange is complete,each transmitting device encrypts and/or signs each transmission usingthe symmetric key before transmitting data to the receiving device.

Apparatus and Method for Establishing Secure Communication Channels inan Internet of Things (IOT) System

In one embodiment of the invention, encryption and decryption of data isperformed between the IoT service 120 and each IoT device 101,regardless of the intermediate devices used to support the communicationchannel (e.g., such as the user's mobile device 611 and/or the IoT hub110). One embodiment which communicates via an IoT hub 110 isillustrated in FIG. 16A and another embodiment which does not require anIoT hub is illustrated in FIG. 16B.

Turning first to FIG. 16A, the IoT service 120 includes an encryptionengine 1660 which manages a set of “service session keys” 1650 and eachIoT device 101 includes an encryption engine 1661 which manages a set of“device session keys” 1651 for encrypting/decrypting communicationbetween the IoT device 101 and IoT service 120. The encryption enginesmay rely on different hardware modules when performing thesecurity/encryption techniques described herein including a hardwaresecurity module 1630-1631 for (among other things) generating a sessionpublic/private key pair and preventing access to the private session keyof the pair and a key stream generation module 1640-1641 for generatinga key stream using a derived secret. In one embodiment, the servicesession keys 1650 and the device session keys 1651 comprise relatedpublic/private key pairs. For example, in one embodiment, the devicesession keys 1651 on the IoT device 101 include a public key of the IoTservice 120 and a private key of the IoT device 101. As discussed indetail below, in one embodiment, to establish a secure communicationsession, the public/private session key pairs, 1650 and 1651, are usedby each encryption engine, 1660 and 1661, respectively, to generate thesame secret which is then used by the SKGMs 1640-1641 to generate a keystream to encrypt and decrypt communication between the IoT service 120and the IoT device 101. Additional details associated with generationand use of the secret in accordance with one embodiment of the inventionare provided below.

In FIG. 16A, once the secret has been generated using the keys1650-1651, the client will always send messages to the IoT device 101through the IoT service 120, as indicated by Clear transaction 1611.“Clear” as used herein is meant to indicate that the underlying messageis not encrypted using the encryption techniques described herein.However, as illustrated, in one embodiment, a secure sockets layer (SSL)channel or other secure channel (e.g., an Internet Protocol Security(IPSEC) channel) is established between the client device 611 and IoTservice 120 to protect the communication. The encryption engine 1660 onthe IoT service 120 then encrypts the message using the generated secretand transmits the encrypted message to the IoT hub 110 at 1602. Ratherthan using the secret to encrypt the message directly, in oneembodiment, the secret and a counter value are used to generate a keystream, which is used to encrypt each message packet. Details of thisembodiment are described below with respect to FIG. 17.

As illustrated, an SSL connection or other secure channel may beestablished between the IoT service 120 and the IoT hub 110. The IoT hub110 (which does not have the ability to decrypt the message in oneembodiment) transmits the encrypted message to the IoT device at 1603(e.g., over a Bluetooth Low Energy (BTLE) communication channel). Theencryption engine 1661 on the IoT device 101 may then decrypt themessage using the secret and process the message contents. In anembodiment which uses the secret to generate a key stream, theencryption engine 1661 may generate the key stream using the secret anda counter value and then use the key stream for decryption of themessage packet.

The message itself may comprise any form of communication between theIoT service 120 and IoT device 101. For example, the message maycomprise a command packet instructing the IoT device 101 to perform aparticular function such as taking a measurement and reporting theresult back to the client device 611 or may include configuration datato configure the operation of the IoT device 101.

If a response is required, the encryption engine 1661 on the IoT device101 uses the secret or a derived key stream to encrypt the response andtransmits the encrypted response to the IoT hub 110 at 1604, whichforwards the response to the IoT service 120 at 1605. The encryptionengine 1660 on the IoT service 120 then decrypts the response using thesecret or a derived key stream and transmits the decrypted response tothe client device 611 at 1606 (e.g., over the SSL or other securecommunication channel).

FIG. 16B illustrates an embodiment which does not require an IoT hub.Rather, in this embodiment, communication between the IoT device 101 andIoT service 120 occurs through the client device 611 (e.g., as in theembodiments described above with respect to FIGS. 6-9B). In thisembodiment, to transmit a message to the IoT device 101 the clientdevice 611 transmits an unencrypted version of the message to the IoTservice 120 at 1611. The encryption engine 1660 encrypts the messageusing the secret or the derived key stream and transmits the encryptedmessage back to the client device 611 at 1612. The client device 611then forwards the encrypted message to the IoT device 101 at 1613, andthe encryption engine 1661 decrypts the message using the secret or thederived key stream. The IoT device 101 may then process the message asdescribed herein. If a response is required, the encryption engine 1661encrypts the response using the secret and transmits the encryptedresponse to the client device 611 at 1614, which forwards the encryptedresponse to the IoT service 120 at 1615. The encryption engine 1660 thendecrypts the response and transmits the decrypted response to the clientdevice 611 at 1616.

FIG. 17 illustrates a key exchange and key stream generation which mayinitially be performed between the IoT service 120 and the IoT device101. In one embodiment, this key exchange may be performed each time theIoT service 120 and IoT device 101 establish a new communicationsession. Alternatively, the key exchange may be performed and theexchanged session keys may be used for a specified period of time (e.g.,a day, a week, etc). While no intermediate devices are shown in FIG. 17for simplicity, communication may occur through the IoT hub 110 and/orthe client device 611.

In one embodiment, the encryption engine 1660 of the IoT service 120sends a command to the HSM 1630 (e.g., which may be such as a CloudHSMoffered by Amazon®) to generate a session public/private key pair. TheHSM 1630 may subsequently prevent access to the private session key ofthe pair. Similarly, the encryption engine on the IoT device 101 maytransmit a command to the HSM 1631 (e.g., such as an Atecc508 HSM fromAtmel Corporation®) which generates a session public/private key pairand prevents access to the session private key of the pair. Of course,the underlying principles of the invention are not limited to anyspecific type of encryption engine or manufacturer.

In one embodiment, the IoT service 120 transmits its session public keygenerated using the HSM 1630 to the IoT device 101 at 1701. The IoTdevice uses its HSM 1631 to generate its own session public/private keypair and, at 1702, transmits its public key of the pair to the IoTservice 120. In one embodiment, the encryption engines 1660-1661 use anElliptic curve Diffie-Hellman (ECDH) protocol, which is an anonymous keyagreement that allows two parties with an elliptic curve public-privatekey pair, to establish a shared secret. In one embodiment, using thesetechniques, at 1703, the encryption engine 1660 of the IoT service 120generates the secret using the IoT device session public key and its ownsession private key. Similarly, at 1704, the encryption engine 1661 ofthe IoT device 101 independently generates the same secret using the IoTservice 120 session public key and its own session private key. Morespecifically, in one embodiment, the encryption engine 1660 on the IoTservice 120 generates the secret according to the formula secret=IoTdevice session pub key*IoT service session private key, where ‘*’ meansthat the IoT device session public key is point-multiplied by the IoTservice session private key. The encryption engine 1661 on the IoTdevice 101 generates the secret according to the formula secret=IoTservice session pub key*IoT device session private key, where the IoTservice session public key is point multiplied by the IoT device sessionprivate key. In the end, the IoT service 120 and IoT device 101 haveboth generated the same secret to be used to encrypt communication asdescribed below. In one embodiment, the encryption engines 1660-1661rely on a hardware module such as the KSGMs 1640-1641 respectively toperform the above operations for generating the secret.

Once the secret has been determined, it may be used by the encryptionengines 1660 and 1661 to encrypt and decrypt data directly.Alternatively, in one embodiment, the encryption engines 1660-1661 sendcommands to the KSGMs 1640-1641 to generate a new key stream using thesecret to encrypt/decrypt each data packet (i.e., a new key stream datastructure is generated for each packet). In particular, one embodimentof the key stream generation module 1640-1641 implements aGalois/Counter Mode (GCM) in which a counter value is incremented foreach data packet and is used in combination with the secret to generatethe key stream. Thus, to transmit a data packet to the IoT service 120,the encryption engine 1661 of the IoT device 101 uses the secret and thecurrent counter value to cause the KSGMs 1640-1641 to generate a new keystream and increment the counter value for generating the next keystream. The newly-generated key stream is then used to encrypt the datapacket prior to transmission to the IoT service 120. In one embodiment,the key stream is XORed with the data to generate the encrypted datapacket. In one embodiment, the IoT device 101 transmits the countervalue with the encrypted data packet to the IoT service 120. Theencryption engine 1660 on the IoT service then communicates with theKSGM 1640 which uses the received counter value and the secret togenerate the key stream (which should be the same key stream because thesame secret and counter value are used) and uses the generated keystream to decrypt the data packet.

In one embodiment, data packets transmitted from the IoT service 120 tothe IoT device 101 are encrypted in the same manner. Specifically, acounter is incremented for each data packet and used along with thesecret to generate a new key stream. The key stream is then used toencrypt the data (e.g., performing an XOR of the data and the keystream) and the encrypted data packet is transmitted with the countervalue to the IoT device 101. The encryption engine 1661 on the IoTdevice 101 then communicates with the KSGM 1641 which uses the countervalue and the secret to generate the same key stream which is used todecrypt the data packet. Thus, in this embodiment, the encryptionengines 1660-1661 use their own counter values to generate a key streamto encrypt data and use the counter values received with the encrypteddata packets to generate a key stream to decrypt the data.

In one embodiment, each encryption engine 1660-1661 keeps track of thelast counter value it received from the other and includes sequencinglogic to detect whether a counter value is received out of sequence orif the same counter value is received more than once. If a counter valueis received out of sequence, or if the same counter value is receivedmore than once, this may indicate that a replay attack is beingattempted. In response, the encryption engines 1660-1661 may disconnectfrom the communication channel and/or may generate a security alert.

FIG. 18 illustrates an exemplary encrypted data packet employed in oneembodiment of the invention comprising a 4-byte counter value 1800, avariable-sized encrypted data field 1801, and a 6-byte tag 1802. In oneembodiment, the tag 1802 comprises a checksum value to validate thedecrypted data (once it has been decrypted).

As mentioned, in one embodiment, the session public/private key pairs1650-1651 exchanged between the IoT service 120 and IoT device 101 maybe generated periodically and/or in response to the initiation of eachnew communication session.

One embodiment of the invention implements additional techniques forauthenticating sessions between the IoT service 120 and IoT device 101.In particular, in one embodiment, hierarchy of public/private key pairsis used including a master key pair, a set of factory key pairs, and aset of IoT service key pairs, and a set of IoT device key pairs. In oneembodiment, the master key pair comprises a root of trust for all of theother key pairs and is maintained in a single, highly secure location(e.g., under the control of the organization implementing the IoTsystems described herein). The master private key may be used togenerate signatures over (and thereby authenticate) various other keypairs such as the factory key pairs. The signatures may then be verifiedusing the master public key. In one embodiment, each factory whichmanufactures IoT devices is assigned its own factory key pair which maythen be used to authenticate IoT service keys and IoT device keys. Forexample, in one embodiment, a factory private key is used to generate asignature over IoT service public keys and IoT device public keys. Thesesignature may then be verified using the corresponding factory publickey. Note that these IoT service/device public keys are not the same asthe “session” public/private keys described above with respect to FIGS.16A-B. The session public/private keys described above are temporary(i.e., generated for a service/device session) while the IoTservice/device key pairs are permanent (i.e., generated at the factory).

With the foregoing relationships between master keys, factory keys,service/device keys in mind, one embodiment of the invention performsthe following operations to provide additional layers of authenticationand security between the IoT service 120 and IoT device 101:

A. In one embodiment, the IoT service 120 initially generates a messagecontaining the following:

-   -   1. The IoT service's unique ID:        -   The IoT service's serial number;        -   a Timestamp;        -   The ID of the factory key used to sign this unique ID;        -   a Class of the unique ID (i.e., a service);        -   IoT service's public key        -   The signature over the unique ID.    -   2. The Factory Certificate including:        -   A timestamp        -   The ID of the master key used to sign the certificate        -   The factory public key        -   The signature of the Factory Certificate    -   3. IoT service session public key (as described above with        respect to FIGS. 16A-B)    -   4. IoT service session public key signature (e.g., signed with        the IoT service's private key)

B. In one embodiment, the message is sent to the IoT device on thenegotiation channel (described below). The IoT device parses the messageand:

-   -   1. Verifies the signature of the factory certificate (only if        present in the message payload)    -   2. Verifies the signature of the unique ID using the key        identified by the unique ID    -   3. Verifies the IoT service session public key signature using        the IoT service's public key from the unique ID    -   4. Saves the IoT service's public key as well as the IoT        service's session public key    -   5. Generates the IoT device session key pair

C. The IoT device then generates a message containing the following:

-   -   1. IoT device's unique ID        -   IoT device serial number        -   Timestamp        -   ID of factory key used to sign this unique ID        -   Class of unique ID (i.e., IoT device)        -   IoT device's public key        -   Signature of unique ID    -   2. IoT device's session public key    -   3. Signature of (IoT device session public key+IoT service        session public key) signed with IoT device's key

D. This message is sent back to the IoT service. The IoT service parsesthe message and:

-   -   1. Verifies the signature of the unique ID using the factory        public key    -   2. Verifies the signature of the session public keys using the        IoT device's public key    -   3. Saves the IoT device's session public key

E. The IoT service then generates a message containing a signature of(IoT device session public key+IoT service session public key) signedwith the IoT service's key.

F. The IoT device parses the message and:

-   -   1. Verifies the signature of the session public keys using the        IoT service's public key    -   2. Generates the key stream from the IoT device session private        key and the IoT service's session public key    -   3. The IoT device then sends a “messaging available” message.

G. The IoT service then does the following:

-   -   1. Generates the key stream from the IoT service session private        key and the IoT device's session public key    -   2. Creates a new message on the messaging channel which contains        the following:        -   Generates and stores a random 2 byte value        -   Set attribute message with the boomerang attribute Id            (discussed below) and the random value

H. The IoT device receives the message and:

-   -   1. Attempts to decrypt the message    -   2. Emits an Update with the same value on the indicated        attribute Id

I. The IoT service recognizes the message payload contains a boomerangattribute update and:

-   -   1. Sets its paired state to true    -   2. Sends a pairing complete message on the negotiator channel

J. IoT device receives the message and sets his paired state to true

While the above techniques are described with respect to an “IoTservice” and an “IoT device,” the underlying principles of the inventionmay be implemented to establish a secure communication channel betweenany two devices including user client devices, servers, and Internetservices.

The above techniques are highly secure because the private keys arenever shared over the air (in contrast to current Bluetooth pairingtechniques in which a secret is transmitted from one party to theother). An attacker listening to the entire conversation will only havethe public keys, which are insufficient to generate the shared secret.These techniques also prevent a man-in-the-middle attack by exchangingsigned public keys. In addition, because GCM and separate counters areused on each device, any kind of “replay attack” (where a man in themiddle captures the data and sends it again) is prevented. Someembodiments also prevent replay attacks by using asymmetrical counters.

Techniques for Exchanging Data and Commands without Formally PairingDevices

GATT is an acronym for the Generic Attribute Profile, and it defines theway that two Bluetooth Low Energy (BTLE) devices transfer data back andforth. It makes use of a generic data protocol called the AttributeProtocol (ATT), which is used to store Services, Characteristics andrelated data in a simple lookup table using 16-bit Characteristic IDsfor each entry in the table. Note that while the “characteristics” aresometimes referred to as “attributes.”

On Bluetooth devices, the most commonly used characteristic is thedevices “name” (having characteristic ID 10752 (0x2A00)). For example, aBluetooth device may identify other Bluetooth devices within itsvicinity by reading the “Name” characteristic published by those otherBluetooth devices using GATT. Thus, Bluetooth device have the inherentability to exchange data without formally pairing/bonding the devices(note that “paring” and “bonding” are sometimes used interchangeably;the remainder of this discussion will use the term “pairing”).

One embodiment of the invention takes advantage of this capability tocommunicate with BTLE-enabled IoT devices without formally pairing withthese devices. Pairing with each individual IoT device would extremelyinefficient because of the amount of time required to pair with eachdevice and because only one paired connection may be established at atime.

FIG. 19 illustrates one particular embodiment in which a Bluetooth (BT)device 1910 establishes a network socket abstraction with a BTcommunication module 1901 of an IoT device 101 without formallyestablishing a paired BT connection. The BT device 1910 may be includedin an IoT hub 110 and/or a client device 611 such as shown in FIG. 16A.As illustrated, the BT communication module 1901 maintains a datastructure containing a list of characteristic IDs, names associated withthose characteristic IDs and values for those characteristic IDs. Thevalue for each characteristic may be stored within a 20-byte bufferidentified by the characteristic ID in accordance with the current BTstandard. However, the underlying principles of the invention are notlimited to any particular buffer size.

In the example in FIG. 19, the “Name” characteristic is a BT-definedcharacteristic which is assigned a specific value of “IoT Device 14.”One embodiment of the invention specifies a first set of additionalcharacteristics to be used for negotiating a secure communicationchannel with the BT device 1910 and a second set of additionalcharacteristics to be used for encrypted communication with the BTdevice 1910. In particular, a “negotiation write” characteristic,identified by characteristic ID<65532> in the illustrated example, maybe used to transmit outgoing negotiation messages and the “negotiationread” characteristic, identified by characteristic ID<65533> may be usedto receive incoming negotiation messages. The “negotiation messages” mayinclude messages used by the BT device 1910 and the BT communicationmodule 1901 to establish a secure communication channel as describedherein. By way of example, in FIG. 17, the IoT device 101 may receivethe IoT service session public key 1701 via the “negotiation read”characteristic <65533>. The key 1701 may be transmitted from the IoTservice 120 to a BTLE-enabled IoT hub 110 or client device 611 which maythen use GATT to write the key 1701 to the negotiation read value bufferidentified by characteristic ID<65533>. IoT device application logic1902 may then read the key 1701 from the value buffer identified bycharacteristic ID<65533> and process it as described above (e.g., usingit to generate a secret and using the secret to generate a key stream,etc).

If the key 1701 is greater than 20 bytes (the maximum buffer size insome current implementations), then it may be written in 20-byteportions. For example, the first 20 bytes may be written by the BTcommunication module 1903 to characteristic ID<65533> and read by theIoT device application logic 1902, which may then write anacknowledgement message to the negotiation write value buffer identifiedby characteristic ID<65532>. Using GATT, the BT communication module1903 may read this acknowledgement from characteristic ID<65532> andresponsively write the next 20 bytes of the key 1701 to the negotiationread value buffer identified by characteristic ID<65533>. In thismanner, a network socket abstraction defined by characteristic IDs<65532> and <65533> is established for exchanging negotiation messagesused to establish a secure communication channel.

In one embodiment, once the secure communication channel is established,a second network socket abstraction is established using characteristicID<65534> (for transmitting encrypted data packets from IoT device 101)and characteristic ID<65533> (for receiving encrypted data packets byIoT device). That is, when BT communication module 1903 has an encrypteddata packet to transmit (e.g., such as encrypted message 1603 in FIG.16A), it starts writing the encrypted data packet, 20 bytes at a time,using the message read value buffer identified by characteristicID<65533>. The IoT device application logic 1902 will then read theencrypted data packet, 20 bytes at a time, from the read value buffer,sending acknowledgement messages to the BT communication module 1903 asneeded via the write value buffer identified by characteristicID<65532>.

In one embodiment, the commands of GET, SET, and UPDATE described beloware used to exchange data and commands between the two BT communicationmodules 1901 and 1903. For example, the BT communication module 1903 maysend a packet identifying characteristic ID<65533> and containing theSET command to write into the value field/buffer identified bycharacteristic ID<65533> which may then be read by the IoT deviceapplication logic 1902. To retrieve data from the IoT device 101, the BTcommunication module 1903 may transmit a GET command directed to thevalue field/buffer identified by characteristic ID<65534>. In responseto the GET command, the BT communication module 1901 may transmit anUPDATE packet to the BT communication module 1903 containing the datafrom the value field/buffer identified by characteristic ID<65534>. Inaddition, UPDATE packets may be transmitted automatically, in responseto changes in a particular attribute on the IoT device 101. For example,if the IoT device is associated with a lighting system and the userturns on the lights, then an UPDATE packet may be sent to reflect thechange to the on/off attribute associated with the lighting application.

FIG. 20 illustrates exemplary packet formats used for GET, SET, andUPDATE in accordance with one embodiment of the invention. In oneembodiment, these packets are transmitted over the message write <65534>and message read <65533> channels following negotiation. In the GETpacket 2001, a first 1-byte field includes a value (0X10) whichidentifies the packet as a GET packet. A second 1-byte field includes arequest ID, which uniquely identifies the current GET command (i.e.,identifies the current transaction with which the GET command isassociated). For example, each instance of a GET command transmittedfrom a service or device may be assigned a different request ID. Thismay be done, for example, by incrementing a counter and using thecounter value as the request ID. However, the underlying principles ofthe invention are not limited to any particular manner for setting therequest ID.

A 2-byte attribute ID identifies the application-specific attribute towhich the packet is directed. For example, if the GET command is beingsent to IoT device 101 illustrated in FIG. 19, the attribute ID may beused to identify the particular application-specific value beingrequested. Returning to the above example, the GET command may bedirected to an application-specific attribute ID such as power status ofa lighting system, which comprises a value identifying whether thelights are powered on or off (e.g., 1=on, 0=off). If the IoT device 101is a security apparatus associated with a door, then the value field mayidentify the current status of the door (e.g., 1=opened, 0=closed). Inresponse to the GET command, a response may be transmitting containingthe current value identified by the attribute ID.

The SET packet 2002 and UPDATE packet 2003 illustrated in FIG. 20 alsoinclude a first 1-byte field identifying the type of packet (i.e., SETand UPDATE), a second 1-byte field containing a request ID, and a 2-byteattribute ID field identifying an application-defined attribute. Inaddition, the SET packet includes a 2-byte length value identifying thelength of data contained in an n-byte value data field. The value datafield may include a command to be executed on the IoT device and/orconfiguration data to configure the operation of the IoT device in somemanner (e.g., to set a desired parameter, to power down the IoT device,etc). For example, if the IoT device 101 controls the speed of a fan,the value field may reflect the current fan speed.

The UPDATE packet 2003 may be transmitted to provide an update of theresults of the SET command. The UPDATE packet 2003 includes a 2-bytelength value field to identify the length of the n-byte value data fieldwhich may include data related to the results of the SET command. Inaddition, a 1-byte update state field may identify the current state ofthe variable being updated. For example, if the SET command attempted toturn off a light controlled by the IoT device, the update state fieldmay indicate whether the light was successfully turned off.

FIG. 21 illustrates an exemplary sequence of transactions between theIoT service 120 and an IoT device 101 involving the SET and UPDATEcommands. Intermediary devices such as the IoT hub and the user's mobiledevice are not shown to avoid obscuring the underlying principles of theinvention. At 2101, the SET command 2101 is transmitted form the IoTservice to the IoT device 101 and received by the BT communicationmodule 1901 which responsively updates the GATT value buffer identifiedby the characteristic ID at 2102. The SET command is read from the valuebuffer by the low power microcontroller (MCU) 200 at 2103 (or by programcode being executed on the low power MCU such as IoT device applicationlogic 1902 shown in FIG. 19). At 2104, the MCU 200 or program codeperforms an operation in response to the SET command. For example, theSET command may include an attribute ID specifying a new configurationparameter such as a new temperature or may include a state value such ason/off (to cause the IoT device to enter into an “on” or a low powerstate). Thus, at 2104, the new value is set in the IoT device and anUPDATE command is returned at 2105 and the actual value is updated in aGATT value field at 2106. In some cases, the actual value will be equalto the desired value. In other cases, the updated value may be different(i.e., because it may take time for the IoT device 101 to update certaintypes of values). Finally, at 2107, the UPDATE command is transmittedback to the IoT service 120 containing the actual value from the GATTvalue field.

FIG. 22 illustrates a method for implementing a secure communicationchannel between an IoT service and an IoT device in accordance with oneembodiment of the invention. The method may be implemented within thecontext of the network architectures described above but is not limitedto any specific architecture.

At 2201, the IoT service creates an encrypted channel to communicatewith the IoT hub using elliptic curve digital signature algorithm(ECDSA) certificates. At 2202, the IoT service encrypts data/commands inIoT device packets using the a session secret to create an encrypteddevice packet. As mentioned above, the session secret may beindependently generated by the IoT device and the IoT service. At 2203,the IoT service transmits the encrypted device packet to the IoT hubover the encrypted channel. At 2204, without decrypting, the IoT hubpasses the encrypted device packet to the IoT device. At 22-5, the IoTdevice uses the session secret to decrypt the encrypted device packet.As mentioned, in one embodiment this may be accomplished by using thesecret and a counter value (provided with the encrypted device packet)to generate a key stream and then using the key stream to decrypt thepacket. At 2206, the IoT device then extracts and processes the dataand/or commands contained within the device packet.

Thus, using the above techniques, bi-directional, secure network socketabstractions may be established between two BT-enabled devices withoutformally pairing the BT devices using standard pairing techniques. Whilethese techniques are described above with respect to an IoT device 101communicating with an IoT service 120, the underlying principles of theinvention may be implemented to negotiate and establish a securecommunication channel between any two BT-enabled devices.

FIGS. 23A-C illustrate a detailed method for pairing devices inaccordance with one embodiment of the invention. The method may beimplemented within the context of the system architectures describedabove, but is not limited to any specific system architectures.

At 2301, the IoT Service creates a packet containing serial number andpublic key of the IoT Service. At 2302, the IoT Service signs the packetusing the factory private key. At 2303, the IoT Service sends the packetover an encrypted channel to the IoT hub and at 2304 the IoT hubforwards the packet to IoT device over an unencrypted channel. At 2305,the IoT device verifies the signature of packet and, at 2306, the IoTdevice generates a packet containing the serial number and public key ofthe IoT Device. At 2307, the IoT device signs the packet using thefactory private key and at 2308, the IoT device sends the packet overthe unencrypted channel to the IoT hub.

At 2309, the IoT hub forwards the packet to the IoT service over anencrypted channel and at 2310, the IoT Service verifies the signature ofthe packet. At 2311, the IoT Service generates a session key pair, andat 2312 the IoT Service generates a packet containing the session publickey. The IoT Service then signs the packet with IoT Service private keyat 2313 and, at 2314, the IoT Service sends the packet to the IoT hubover the encrypted channel.

Turning to FIG. 23B, the IoT hub forwards the packet to the IoT deviceover the unencrypted channel at 2315 and, at 2316, the IoT deviceverifies the signature of packet. At 2317 the IoT device generatessession key pair (e.g., using the techniques described above), and, at2318, an IoT device packet is generated containing the IoT devicesession public key. At 2319, the IoT device signs the IoT device packetwith IoT device private key. At 2320, the IoT device sends the packet tothe IoT hub over the unencrypted channel and, at 2321, the IoT hubforwards the packet to the IoT service over an encrypted channel.

At 2322, the IoT service verifies the signature of the packet (e.g.,using the IoT device public key) and, at 2323, the IoT service uses theIoT service private key and the IoT device public key to generate thesession secret (as described in detail above). At 2324, the IoT deviceuses the IoT device private key and IoT service public key to generatethe session secret (again, as described above) and, at 2325, the IoTdevice generates a random number and encrypts it using the sessionsecret. At 2326, the IoT service sends the encrypted packet to IoT hubover the encrypted channel. At 2327, the IoT hub forwards the encryptedpacket to the IoT device over the unencrypted channel. At 2328, the IoTdevice decrypts the packet using the session secret.

Turning to FIG. 23C, the IoT device re-encrypts the packet using thesession secret at 2329 and, at 2330, the IoT device sends the encryptedpacket to the IoT hub over the unencrypted channel. At 2331, the IoT hubforwards the encrypted packet to the IoT service over the encryptedchannel. The IoT service decrypts the packet using the session secret at2332. At 2333 the IoT service verifies that the random number matchesthe random number it sent. The IoT service then sends a packetindicating that pairing is complete at 2334 and all subsequent messagesare encrypted using the session secret at 2335.

Apparatus and Method for Modifying Packet Interval Timing to Identify aData Transfer Condition

Bluetooth Low Energy (BTLE) devices send advertising packets separatedby an “advertising interval” to establish connections between devices. ABTLE peripheral device broadcasts advertising packets to every devicearound it using the advertising interval. A receiving BTLE device canthen act on this information or connect to receive more information.

The 2.4 GHz spectrum for BTLE extends from 2402 MHz to 2480 MHz and uses40 1 MHz wide channels, numbered 0 to 39. Each channel is separated by 2MHz. Channels 37, 38, and 39 are used only for sending advertisementpackets. The rest are used for data exchange during a connection. Duringa BTLE advertisement, a BTLE peripheral device transmits packets on the3 advertising channels one after the other. A central device scanningfor devices or beacons will listen to those channels for the advertisingpackets, which helps it discover devices nearby. Channels 37, 38 and 39are intentionally spread across the 2.4 GHz spectrum (i.e., channels 37and 39 are the first and last channels in the band and channel 38 is inthe middle). If any single advertising channel is blocked, the otherchannels are likely to be free since they are separated by several MHzof bandwidth.

When an IoT device has data to be transmitted, it would normally includea flag as part of its advertisement packets to indicate that data isready to be sent. In one embodiment of the invention, rather than usingthis flag, an IoT device adjusts the advertising interval to indicatethat it has pending data. For example, if T is the time betweenadvertisement packets when no data is pending, a different advertisinginterval such as 0.75 T, 0.5 T, or 1.25 T may be selected to indicatethat data is pending. In one embodiment, the two different intervals areprogrammable based on the specific requirements of the application andto make it harder to determine which interval means which state.

FIG. 24 illustrates one embodiment of an IoT device 101 in which theBTLE communication interface 2410 includes advertising intervalselection logic 2411 which adjusts the advertising interval when data isready to be transmitted. In addition, the BTLE communication interface2420 on the IoT hub 110 includes advertising interval detection logic2421 to detect the change in the advertising interval, provide anacknowledgement, and receive the data.

In particular, in the illustrated embodiment, an application 2401 on theIoT device 101 indicates that it has data to be sent. In response, theadvertising interval selection logic 2411 modifies the advertisinginterval to notify the IoT hub 110 that data is to be transmitted (e.g.,changing the interval to 0.75 T or some other value). When theadvertising interval detection logic 2421 detects the change, the BTLEcommunication interface 2420 connects to the BTLE communicationinterface 2410 of the IoT device 101, indicating that it is ready toreceive the data. The BTLE communication interface 2410 of the IoTdevice 101 then transmits the data to the BTLE communication interface2420 of the IoT hub. The IoT hub may then pass the data through to theIoT service 120 and/or to the user's client device (not shown). Afterthe data has been transmitted, the advertising interval selection logic2411 may then revert back to the normal advertising interval (e.g.,AI=T).

In one embodiment of the invention, a secure communication channel isestablished between the IoT device 101 and the IoT service 120 using oneor more of the security/encryption techniques described above (see,e.g., FIGS. 16A-23C and associated text). For example, in oneembodiment, the IoT service 120 performs a key exchange with the IoTdevice 101 as described above to encrypt all communication between theIoT device 101 and the IoT service 120.

A method in accordance with one embodiment of the invention isillustrated in FIG. 25. The method may be implemented within the contextof the system architectures described above, but is not limited to anyparticular system architectures.

At 2500, the IoT device uses the standard advertising interval whengenerating advertising packets (e.g., separated by time T). The IoTdevice maintains the standard advertising interval at 2502 until it hasdata to send, determined at 2501. Then, at 2503, the IoT device switchesthe advertising interval to indicate that it has data to transmit. At2504, the IoT hub or other network device establishes a connection withthe IoT device, thereby allowing the IoT device to transmit its data.Finally, at 2505, the IoT device transmits its pending data to the IoThub.

It should be noted that while the advertising interval techniques aredescribed herein within the context of the BTLE protocol, the underlyingprinciples of the invention are not limited to BTLE. In fact, theunderlying principles of the invention may be implemented on any systemwhich selects an advertising interval for establishing wirelesscommunication between devices.

In addition, while a dedicated IoT hub 110 is illustrated in manyembodiments above, a dedicated IoT hub hardware platform is not requiredfor complying with the underlying principles of the invention. Forexample, the various IoT hubs described above may be implemented assoftware executed within various other networking devices such asiPhones® and Android® devices. In fact, the IoT hubs discussed above maybe implemented on any device capable of communicating with IoT devices(e.g., using BTLE or other local wireless protocol) and establishing aconnection over the Internet (e.g., to an IoT service using a WiFi orcellular data connection).

System and Method for Reducing Wireless Traffic when Connecting an IotHub to an Iot Device

When multiple IoT hubs are configured in a particular location, a singleIoT device may have the ability to connect with each IoT hub withinrange. As mentioned, an IoT device may use an advertising channel tonotify any IoT hubs within range that it is “connectable” so that an IoThub may connect to it to transmit commands and/or data. When multipleIoT hubs are within range of an IoT device, the IoT service may attemptto transmit commands/data addressed to the IoT device through each ofthese IoT hubs, thereby wasting wireless bandwidth and reducingperformance (e.g., due to interference resulting from the multipletransmissions).

To address this issue, one embodiment of the invention implementstechniques to ensure that once a particular IoT hub has successfullyconnected to the IoT device, the other IoT hubs will be notified to stopattempting to transmit the commands/data. This embodiment will bedescribed with respect to FIGS. 26A-C which shows an exemplary set ofIoT hubs 110-112 all of which are within range of an IoT device 101. Asa result, the secure wireless communication module 2610 of the IoTdevice 101 is capable of seeing and connecting to the secure wirelesscommunication modules 2650-2652 of each of the IoT hubs 110-112. In oneembodiment, the secure wireless communication modules comprise thesecure BTLE modules described above. However, the underlying principlesof the invention are not limited to any particular wireless standard.

As illustrated in FIG. 26A, in one embodiment, the secure wirelesscommunication module 2610 of the IoT device 101 includes advertisingcontrol logic 2610 to periodically transmit an advertising beacon tonearby wireless communication devices indicating that it is“connectable” (i.e., may be connected to by any devices within range).Any IoT hubs 110-112 which receive the advertising beacon are then awareof the IoT device 101 and the secure wireless communication modules2650-2652 may connect to the secure wireless communication module 2610of the IoT device 101 when commands/data have been addressed to the IoTdevice 101 by the IoT service.

As illustrated in FIG. 26B, in one embodiment, when the IoT service hasdata/commands for the IoT device 101 it may transmit the data/commandsto all of the IoT hubs 110-112 within the particular location (e.g., allIoT hubs associated with the user's account and/or within range of theIoT device 101). As illustrated, each of the IoT hubs 110-112 may thenattempt to connect with the IoT device 101 to provide the commands/data.

As illustrated in FIG. 26C, in one embodiment, only a single IoT hub 111will successfully connect to the IoT device 101 and provide thecommands/data for processing by the IoT device 101. With certainwireless communication protocols such as BTLE, once a connection hasbeen made, the secure wireless communication module 2610 will stoptransmitting advertising beacons. As such, the other IoT hubs 110, 112will not have any way of knowing that the IoT device 101 hassuccessfully received the data from IoT hub 111 and will continue toattempt to transmit the commands/data, thereby consuming wirelessbandwidth and creating interference.

To address this limitation, one embodiment of the secure wirelesscommunication module 2610 includes a connection manager 2611 which, upondetecting a successful connection with the secure wireless communicationmodule 2651 of the IoT hub 111, causes the advertising control module2612 to continue transmitting advertising beacons. However, instead ofindicating that the IoT device 101 is “connectable,” the new advertisingbeacons indicate that the IoT device 101 is “not connectable.” In oneembodiment, in response to the “not connectable” indication, the securewireless communication modules 2650, 2652 of the IoT hubs 110, 112 willstop attempting to transmit the commands/data to the IoT device, therebyreducing unnecessary wireless traffic.

The above techniques provide an elegant solution to undesirable wirelesstraffic using techniques which may be readily implemented on top ofexisting wireless protocols. For example, in one embodiment, the“connectable” and “not connectable” indications are implemented withinthe context of the BTLE standard. However, as mentioned, the underlyingprinciples of the invention may be implemented using a variety ofdifferent wireless network protocols.

A method in accordance with one embodiment of the invention isillustrated in FIG. 27. The method may be implemented within the contextof the system architectures described above, but is not limited to anyparticular system architecture.

At 2701, commands and/or data are transmitted from the IoT servicethrough two or more IoT hubs. For example, the user may be attempting tocontrol an IoT device via an app on the user's mobile device, which isconnected to the IoT service. At 2702, the IoT hubs attempt to connectto the IoT device and one of the IoT hubs successfully connects andprovides the commands/data to the IoT device. As mentioned, the IoT hubsmay be aware of the IoT device as a result of the IoT devicetransmitting a “connectable” indication in an advertising beacon.

At 2703, in response to a successful connection, the IoT device beginstransmitting a “not connectable” advertising beacon, thereby informingany IoT hubs within range that the IoT device is no longer connectable.At 2704, upon receipt of the “not connectable” beacon, the other IoThubs stop attempting to transmit the commands/data to the IoT device.

System and Method for Secure Internet of Things (Iot) DeviceProvisioning

As mentioned above, in one embodiment, when device advertises to an IoThub, it uses an 8-byte “device ID” which the hub and the IoT serviceuses to uniquely identify the IoT device. The device ID may be includedwithin the unique barcode or QR code printed on the IoT device which isread and transmitted to the IoT service to provision/register the IoTdevice in the system. Once provisioned/registered, the device ID is usedto address the IoT device in the system.

One security concern with this implementation is that because thebarcode/QR code data may be transmitted without encryption, it may bepossible to sniff the wireless transmission of the device ID tocompromise the system, thereby allowing another user to associate thedevice ID with his/her account.

In one embodiment, to address this concern, an “association ID” isassociated with each device ID and used during the provisioning processto ensure that the device ID is never transmitted in the clear. Asillustrated in FIG. 28, in this embodiment, the association ID 2812 isincluded in the barcode/QR code printed on the IoT device 101 while thedevice ID 2811 is maintained securely within the secure wirelesscommunication module 2810 which implements the techniques describedabove to ensure secure communication with the IoT service 120. In oneembodiment, the association ID 2812 is an 8 byte ID like the device IDand is unique per IoT device. When a new IoT device 101 is provisionedin the system, the user scans the barcode/QR code containing theassociation ID 2812 with a user device 135 having an IoT app orapplication installed thereon. Alternatively, or in addition, the IoThub 110 may be used to capture the barcode/QR code including theassociation ID.

In either case, the association ID is transmitted to a deviceprovisioning module 2850 on the IoT service 120 which performs a lookupin a device database 2851 which includes an association between eachassociation ID and each device ID. The device provisioning module 2850uses the association ID 2812 to identify the device ID 2811 and thenuses the device ID to provision the new IoT device 101 in the system. Inparticular, once the device ID has been determined from the devicedatabase 2851, the device provisioning module 2850 transmits a commandto the IoT hubs 110 (which may include the user device 135) authorizingthe IoT hubs 110 to communicate with the IoT device 101 using the deviceID 2811.

In one embodiment, the association ID 2812 is generated at a factorywhen the IoT device 101 is manufactured (i.e., when the secure wirelesscommunication module 2810 is provisioned). Both the device ID 2811 andthe association ID 2812 may then be provided to the IoT service andstored within the device database 2851. As illustrated, the devicedatabase 2851 may include an indication specifying whether each devicehas been provisioned. By way of example, this may be a binary value witha first value (e.g., 1) indicating that the IoT device 101 isprovisioned and a second value (e.g., 0) indicating that the IoT deviceis not provisioned. Once the system has provisioned/registered the IoTdevice 101, the device ID may be used because the communication betweenthe IoT service 120 and IoT device 101 is protected using the securitytechniques described above.

In one embodiment, when a user sells an IoT device, the user may releasethe device ID by logging in to the IoT service 120 and releasing the IoTdevice from the user's account. The new user may then provision the IoTdevice and associate the IoT device with his/her account using thedevice provisioning techniques described herein.

A method in accordance with one embodiment of the invention isillustrated in FIG. 29. The method may be implemented within the contextof the system architectures described above, but is not limited to anyparticular system architecture.

At 2901, an association is generated between a device ID and anassociation ID of an IoT device (e.g., at the factory at which the IoTdevice is manufactured). The association ID may be embedded within abarcode/QR code which is stamped on the IoT device. At 2902, theassociation between the device ID and association ID is stored on theIoT service. At 2903, the user purchases the new IoT device and scansthe barcode/QR code containing the association ID (e.g., via the user'smobile device with an app or application installed thereon or via an IoThub with a barcode reader).

At 2904, the association ID is transmitted to the IoT service and, at2905, the association ID is used to identify the device ID. At 2906, theIoT device is provisioned using the device ID. For example, the IoTdevice database may be updated to indicate that this particular deviceID has been provisioned and the IoT service may communicate the deviceID to IoT hubs, instructing the IoT hubs to communicate with the new IoTdevice.

System and Method for Performing Flow Control in an Internet of Things(IoT) System

Local wireless network traffic will increase based on the number of IoTdevices within a given location. Moreover, in some instances, an IoTdevice may be transmitting more data than is reasonable given thefunction being performed by the IoT device. For example,software/hardware on the IoT device may malfunction, or the IoT devicemay be hacked, causing the IoT device to continually transmit unneededdata to the IoT service.

One embodiment of the invention addresses these issues by performingflow control at the IoT hubs, effectively ignoring data traffic whenspecified data thresholds have been reached by a particular IoT device.In one embodiment, each IoT device is configured with a specified set offlow control parameters indicating the amount of data over a period oftime which the IoT device is permitted to transmit. The flow controlparameters may be based on the type of IoT device. For example, certainIoT devices such as door locks and thermostats should typically onlytransmit short packets of data periodically whereas other IoT devicesuch as video cameras may transmit a significantly greater amount ofdata, potentially in a non-periodic manner. Thus, the flow controlparameters may be set to provide a sufficient amount of bandwidth basedon the expected operation of the IoT device in question. In oneembodiment, each IoT device is assigned to a particular flow control“class” based on the data requirements of that IoT device.

Once such embodiment is illustrated in FIG. 30, which shows a pluralityof IoT device 101-103 with secure wireless communication modules 2810,3030, 3040 configured with different sets of flow control parameters3015, 3031, 3041, respectively. In one embodiment, the flow controlparameters specify the frequency and/or amount of data which each IoTdevice is expected to transmit over a specified period of time (e.g.,0.25 Mbytes/hour, 50 Mbytes/hour, 100 Mbytes/day, 10 communicationattempts/day, etc). In one embodiment, the flow control parameters 3015,3031, 3041, may be specified by the IoT service 120 which, asillustrated, includes device management module 3021 to manage a set ofper-device flow control parameters 3020 within an IoT device database2851. For example, once the data transmission requirements for each IoTdevice are determined, the per-flow control parameters 3020 may beupdated to reflect these requirements.

As mentioned, in one embodiment, the device database 2851 includes datatransmission requirements for a plurality of different flow control“classes” (e.g., audiovisual device, temperature device, control device,security device, etc). When a new IoT device is introduced in thesystem, it is then associated with a particular flow control class basedon the requirements of the IoT device and/or the type of IoT device.

The per-device flow control parameters 3020 may be distributed to IoThubs 110 which include flow control management logic 2811 to store acopy of the per-device flow control parameters 3010 within a localdatabase. In one embodiment, the flow control management 2811 maymonitor the amount of data traffic received from and/or transmitted toeach IoT device 101-103. If the amount of data traffic reaches aspecified threshold (as indicated by the per-device flow controlparameters 3010) then the IoT hub 110 may instruct the IoT device tostop transmitting for a period of time and/or may simply block trafficfrom the IoT device.

If a particular IoT device is transmitting/receiving at a level abovethe specified threshold, then this may indicate that the IoT device ismalfunctioning. As such, in one embodiment, the IoT service 120 maytransmit a command to reset the IoT device. If the device is stillcommunicating at a level above the threshold, then the IoT service 120may transmit a software update such as a patch to the IoT device. Oncethe software updated is installed, the IoT device is reset andinitialized with the new software. In addition, a notification may besent from the IoT service to the user device to inform the user that theIoT device is malfunctioning.

In one embodiment, the IoT hub 110 may allow certain types of datatraffic notwithstanding the fact that data communication thresholds havebeen reached. For example, in one embodiment, the IoT hub 110 willpermit certain types of “high priority” notifications even if an IoTdevice has reached its thresholds. By way of example, if the IoT deviceis a door lock or door entry detector, then under certain conditions(e.g., when the house is being monitored), the IoT hub 110 may passthrough data indicating that someone has opened the door in which theIoT device is being used. Similarly, if the IoT device is a heat and/orsmoke detector, then the IoT hub 110 may pass through data indicating analarm condition (e.g., because the temperature has reached a thresholdvalue). Various other types of “high priority” notifications (e.g., suchas those representing a potentially hazardous condition) may be passedthrough by the IoT hub 110 regardless of the current flow controlstatus. In one embodiment, these “high priority” notifications areidentified using different attributes as described below.

A method in accordance with one embodiment of the invention isillustrated in FIG. 31. The method may be implemented within the contextof the system architectures described above, but is not limited to anyparticular system architecture.

At 3101, flow control parameters are specified for each IoT device. Inone embodiment, and IoT device may be assigned to a particular IoTdevice “class” which has a specified set of flow control parametersassociated therewith. At 3102, the flow control parameters are stored onIoT hubs within the IoT system. In one embodiment, each hub may store asubset of all of the IoT device parameters (e.g., only those parametersfor IoT devices that have been provisioned locally).

If an IoT hub detects that a particular IoT device is operating outsideof the specified flow control parameters, determined at 3103, then AT3104 the IoT hub will temporarily refrain from further communicationwith the IoT device (e.g., blocking communication between the IoT deviceand the IoT service). In addition, as mentioned, the IoT service and/orIoT hub may take steps to remedy the problem by rebooting the IoT deviceand/or installing a software update on the IoT device.

System and Method for Managing Internet of Things (Iot) Devices andTraffic Using Attribute Classes

Different IoT devices may be used to perform different functions in agiven location. For example, certain IoT devices may be used to collectdata such as temperature and status (e.g., on/off status) and reportthis data back to the IoT service, where it may be accessed by an enduser and/or used to generate various types of alert conditions. Toenable this implementation, one embodiment of the invention managescollected data, system data, and other forms of data using differenttypes of attribute classes.

FIG. 32 illustrates one embodiment of an IoT device which includes asecure wireless communication module 3218 which communicates with amicrocontroller unit (MCU) 3215 over a serial interface 3216 such as anSerial Peripheral Interface (SPI) bus. The secure wireless communicationmodule 3218 manages the secure communication with the IoT service 120using the techniques described above and the MCU 3215 executes programcode to perform an application-specific function of the IoT device 101.

In one embodiment, various different classes of attributes are used tomanage the data collected by the IoT device and the system configurationrelated to the IoT device. In particular, in the example shown in FIG.32, the attributes include application attributes 3210, systemattributes 3211, and priority notification attributes 3212. In oneembodiment, the application attributes 3210 comprise attributes relatedto the application-specific function performed by the IoT device 101.For example, if the IoT device comprises a security sensor, then theapplication attributes 3210 may include a binary value indicatingwhether a door or window has been opened. If the IoT device comprises atemperature sensor, then the application attributes 3210 may include avalue indicating a current temperature. A virtually unlimited number ofother application-specific attributes may be defined. In one embodiment,the MCU 3215 executes application-specific program code and is onlyprovided with access to the application-specific attributes 3210. Forexample, an application developer may purchase the IoT device 101 withthe secure wireless communication module 3218 and design applicationprogram code to be executed by the MCU 3215. Consequently, theapplication developer will need to have access to application attributesbut will not need to have access to the other types of attributesdescribed below.

In one embodiment, the system attributes 3211 are used for definingoperational and configuration attributes for the IoT device 101 and theIoT system. For example, the system attributes may include networkconfiguration settings (e.g., such as the flow control parametersdiscussed above), the device ID, software versions, advertising intervalselection, security implementation features (as described above) andvarious other low level variables required to allow the IoT device 101to securely communicate with the IoT service.

In one embodiment, a set of priority notification attributes 3212 aredefined based on a level of importance or severity associated with thoseattributes. For example, if a particular attribute is associated with ahazardous condition such as a temperature value reaching a threshold(e.g., when the user accidentally leaves the stove on or when a heatsensor in the user's home triggers) then this attribute may be assignedto a priority notification attribute class. As mentioned above, prioritynotification attributes may be treated differently than otherattributes. For example, when a particular priority notificationattribute reaches a threshold, the IoT hub may pass the value of theattribute to the IoT service, regardless of the current flow controlmechanisms being implemented by the IoT hub. In one embodiment, thepriority notification attributes may also trigger the IoT service togenerate notifications to the user and/or alarm conditions within theuser's home or business (e.g., to alert the user of a potentiallyhazardous condition).

As illustrated in FIG. 32, in one embodiment, the current state of theapplication attributes 3210, system attributes 3211 and prioritynotification attributes 3212 are duplicated/mirrored within the devicedatabase 2851 on the IoT service 120. For example, when a change in oneof the attributes is updated on the IoT device 101, the secure wirelesscommunication module 3218 communicates the change to the devicemanagement logic 3021 on the IoT service 120, which responsively updatesthe value of the attribute within the device database 2851. In addition,when a user updates one of the attributes on the IoT service (e.g.,adjusting a current state or condition such as a desired temperature),the attribute change will be transmitted from the device managementlogic 3021 to the secure wireless communication module 3218 which willthen update its local copy of the attribute. In this way, the attributesare maintained in a consistent manner between the IoT device 101 and theIoT service 120. The attributes may also be accessed from the IoTservice 120 via a user device with an IoT app or application installedand/or by one or more external services 3270. As mentioned, the IoTservice 120 may expose an application programming interface (API) toprovide access to the various different classes of attributes.

In addition, in one embodiment, priority notification processing logic3022 may perform rule-based operations in response to receipt of anotification related to a priority notification attribute 3212. Forexample, if a priority notification attribute indicates a hazardouscondition (e.g., such as an iron or stove being left on by the user),then the priority notification processing logic 3022 may implement a setof rules to attempt to turn off the hazardous device (e.g., sending an“off” command to the device if possible). In one embodiment, thepriority notification processing logic 3022 may utilize other relateddata such as the current location of the user to determine whether toturn off the hazardous device (e.g., if the user is detected leaving thehome when the hazardous device in an “on” state). In addition, thepriority notification processing logic 3022 may transmit an alertcondition to the user's client device to notify the user of thecondition. Various other types of rule sets may be implemented by thepriority notification processing logic 3022 to attempt to address apotentially hazardous or otherwise undesirable condition.

Also shown in FIG. 32 is a set of BTLE attributes 3205 and an attributeaddress decoder 3207. In one embodiment, the BTLE attributes 3205 may beused to establish the read and write ports as described above withrespect to FIGS. 19-20. The attribute address decoder 3207 reads aunique ID code associated with each attribute to determine whichattribute is being received/transmitted and process the attributeaccordingly (e.g., identify where the attribute is stored within thesecure wireless communication module 3218).

Integrated Development Tool for an Internet of Things (IoT) System

One embodiment of the invention includes an integrated development toolto allow IoT developers to readily design new IoT devices, services, andclient apps for end users. In particular, in one embodiment, theintegrated development tool allows the developer to indicate theinput/output functions to be performed by each IoT device, the GUIfeatures to be available to end users, and the back-end functions to beperformed by the IoT service. In response, the integrated developmenttool generates a first profile for the IoT device, a second profile fora client device app, and a third profile for the IoT service to realizean end-to-end, fully-functional IoT implementation with limited effort.

FIG. 33 illustrates one embodiment of an integrated development toolplatform 3301 which includes a development application 3320 with agraphical user interface 3321 usable by a developer to design new IoTimplementations. In one embodiment, the integrated development tool(IDT) platform 3301 comprises a computer system with a storage deviceand memory for storing program code of the development application 3320and a processor for processing the program code during runtime. Inaddition, the various other modules illustrated in FIG. 33 (e.g.,3330-3332) may be implemented as program code executed by the processor.

A development database 3310 is loaded and continually updated with datarelated to different IoT device configurations, user interface featuresfor client-side apps, and IoT service configurations. For example, thedevelopment database 3310 may include data related to different types ofinput/output (I/O) functions to be performed by each of the IoT devices101-102 including, but not limited to analog-to-digital (A/D) functions(e.g., capturing an analog voltage level), digital-to-analog (D/A)functions (e.g., providing an analog voltage output), binary on/offfunctions (e.g., unlocking a door, triggering an alarm, turning on alight, etc), and various General Purpose I/O (GPIO) functions.

In addition, as discussed below, the developer may specify whether theIoT device 102 is to be designed with a stand-alone secure communicationmodule 3218 or whether the IoT device 101 is to be designed with both asecure communication nodule 3218 and MCU 3215 (e.g., interconnected viaan SPI interface as discussed above). A stand-alone implementation maybe used for relatively simpler IoT implementations such as those whichperform simple on/off functions (e.g., a switch integrated on alightbulb) whereas the MCU implementation may be used for more complexdata collection and monitoring (e.g., a remotely-controllable videocamera triggered by a motion sensor).

In one embodiment, once the developer has specified the particular I/Ofunctions to be performed by an IoT device via the developmentapplication 3320, an IoT device engine 3330 uses the configuration dataprovided from the development application to generate an IoT deviceprofile 3340, specifying the configuration parameters for the securecommunication module 3218. This may include, for example, the mode thatthe secure communication module is in, including whether the securecommunication module 3218 is in a stand-alone mode or coupled to an MCU3215. If in stand-alone mode, the IoT device profile 3340 configures thevarious I/O lines of the secure communication module 3218 to perform thefunctions required by the IoT device 102. If used with an MCU 3215, theIoT device profile 3340 may configure the I/O lines 3307 of the securecommunication module 3218 and the I/O lines 3308 of the MCU and may alsospecify how the secure communication module 3218 is to interact with theMCU 3215 (e.g., communicating over an SPI bus to exchange data andcommands with the application executed on the MCU as described above).

In one embodiment, the IoT device profile 3340 may be loaded into anon-volatile memory on the secure communication module 3218 (e.g., Flashmemory) to implement the IoT functions (see, e.g., FIG. 2 showing appcode 203, library code 202, and communication stack code 201 executed bythe low power uC 200). In alternate embodiments, the IoT device profile3340 may be used to configure an application-specific integrated circuitor field-programmable gate array (FPGA). The underlying principles ofthe invention are not limited to any particular configuration for securecommunication module 3218.

In addition to configuring the IoT device, in one embodiment, once thedeveloper has specified the particular I/O functions to be performed byan IoT device via the development application 3320, an IoT device engine3330 uses the configuration data from the development application togenerate a user experience (UX) profile 3341 to be used to implement theIoT app or application on the client device 611. The UX profile, forexample, may specify various graphical I/O elements to be displayedwithin the GUI of the IoT app or application and the configurations tobe used for those graphical I/O elements. For example, if the IoT device102 is a light switch (or other simple on/off device such as a doorlock), then the UX profile may include a simple on/off switch to controlthe IoT device 102. If the IoT device 101 is a video capture device thenthe UX profile may specify a graphical element to cause video to bedisplayed on the client 611 and the specific parameters for displayingthe video (e.g., scaling to be used, location on the client display,etc). A virtually unlimited number of different user interface featuresmay be specified by the UX profile while still complying with theunderlying principles of the invention.

In addition, in one embodiment, an IoT service engine 3332 generates acloud API profile 3342 to accommodate the service-side requirements ofthe new IoT devices 101-102. This may include, for example, the mannerin which the IoT service 120 is to exchange commands and data with thenew IoT devices and/or notifications to be sent to the user's clientdevice 611 in response to data received from the IoT devices. Forexample, if the IoT device is a door lock, then the cloud API profilemay specify that a notification is to be sent to the client device 611whenever the door is opened and the user is not home. In addition, thecloud API profile 3342 may specify the commands to be used to controlthe new IoT devices. In one embodiment, the cloud API profile 3342specifies the manner in which the IoT service 120 is to communicate withexternal IoT services such as the IoT services run by the designer ofthe new IoT devices 101-102 (e.g., exposing an API to the external IoTservices).

A method implemented by an integrated development tool for an IoT systemis illustrated in FIG. 34. The method may be implemented within thecontext of the system architectures described above, but is not limitedto any particular system architecture.

At 3401, the designer enters parameters for the new IoT device via theGUI of the development application. This may include, for example, theI/O functions to be performed by the IoT device and the manner in whichthe IoT device is to interact with the IoT service. At 3402, using datafrom the development application, the IoT device engine generates an IoTdevice profile. In addition to the I/O function specification, this mayinclude an indication as to whether the secure communication module isin stand-alone mode or used with an MCU. At 3403, the IoT device profileis applied to the IoT device. In one embodiment, this involves copyingthe program code to a non-volatile storage on the IoT device.

At 3404, using data from the development application, the client appengine generates a UX profile specifying (among other things) the userinterface to be displayed on the client when interacting with the newIoT devices. At 3405, the UX profile is applied to the client.

At 3406, using data from the development application, the IoT serviceengine generates a cloud API profile specifying the manner in which theIoT service is to interoperate with the new IoT devices, the clientdevice and/or any external IoT services. For example, as describedabove, the IoT service may expose an API to enable communication withone or more external IoT services. At 3405, the cloud API profile isapplied to the IoT cloud service.

Thus, using the integrated development techniques described herein, adeveloper can concurrently program a new IoT device, an IoT service, anda user app, thereby saving a significant amount of time and effortcompared with current implementations in which each component must beindependently programmed and configured.

Integrated Development Platform with Advanced Preview Functionality

One embodiment of the invention generates a preview of client device andIoT device functionality from within the integrated developmentapplication. In particular, one embodiment allows developers to previewa user interface defined within the development application (e.g., theUX profile 3341 discussed above) including different attributedefinitions on all mobile apps where they are logged in with the sameuser account.

FIG. 35 illustrates one embodiment in which virtual device generationlogic 3505 on the IoT service 120 generates a virtual device 3510 usingthe IoT device profile 3340 and the user experience profile 3341specified by the user within the development application 3320. The usermay then interact with and test the virtual device 3510 via thedevelopment application 3320 and/or a mobile app 3522 executed on amobile client device 3520. In one embodiment, the virtual device 3510includes virtualization program code which interprets the deviceattributes 3511 of the IoT device profile 3340 and the presentationdefinitions 3512 from the UX profile 3341 to render a virtualrepresentation of the IoT device 3510. The resulting virtualrepresentation may then be rendered within the client mobile app 3522.

In one embodiment, the user may modify the device attributes 3511 and/orpresentation definitions 3512 via a preview graphical user interface(GUI) 3521 of the development application 3320 (some examples of whichare provided below). As described in detail below, in one embodiment,after making modifications to the device attributes 3511 and/orpresentation definitions 3512, the user manually transfers those changesto the service 120, either by initiating a preview via a preview button3650 or by publishing them via a publish option 3651 (shown, forexample, in FIG. 36G). In another embodiment, any changes made by theuser may be automatically transferred to the service in real time orperiodically.

Once the client 3520 has been logged in to the IoT service 120 via anaccount channel 3560 (i.e., a channel established between the client3520 and IoT service 120 and associated with the user's account), thevirtual device 3510 will apply the changes made by the user via thepreview GUI 3521 and the attributes and presentation features will beupdated within the mobile app 3522.

While some embodiments of the invention are described in the context ofa virtual device 3510, the same principles may be implemented within thecontext of a real IoT device. For example, in one embodiment, thepreview UI button 3650 may be used to update attributes on an IoT devicewhich will then be dynamically reflected in the mobile app 3522.Similarly, as discussed below, the user may modify attributes from themobile app 3522 (e.g., by selecting graphical elements) and view themodifications within the preview GUI 3521.

FIG. 36A illustrates one embodiment of the preview GUI 3521 of thedevelopment application 3320 comprising a plurality of graphicalelements 3515 which may be selected and updated by the user, and apreview UI button 3650 for generating a preview of the updates on themobile client 3520. The graphical elements 3515 comprise a group ofcontrols or widgets representing one or more attributes to be managed bythe IoT device and synchronized with the IoT service as described above.In one embodiment, when a user makes changes to the attributes and/orgraphical features associated with the graphical elements 3515, and thenselects the preview UI button 3650, those changes are updated within thevirtual device 3510 on the IoT service and transmitted to the mobileclient 3520 over the account channel (where they are reflected in the UIof the mobile app 3522).

In FIG. 36B, the user has selected a particular graphical element (an“LED” element to turn an LED ON/OFF) revealing an “attribute tester”window which includes a plurality of fields 3601-3604 through which theuser can make changes to the attribute. In this particular example, theuser may change the attribute name 3601, the data type 3602 used tostore data associated with the attribute, and the current attributevalue 3603. In one embodiment, the user can only change the value ofwritable attributes on this screen. Read-only attributes are displayedonly to show the user value changes on the device side. Read-onlyattributes and fields may be grayed out. An update button 3604 isprovided to implement the changes. In FIG. 36B, the preview userinterface generated on the client 3520 shows graphical elements3610-3611 associated with this particular attribute—i.e., an ON element3610 to indicate when the LED is on and an OFF element 3611 to indicatewhen the LED is off. In FIG. 36B, the attribute value is initially setto 0, resulting in an ON state displayed within the preview GUI (i.e.,element 3610 is highlighted). In FIG. 36C, the user has modified theattribute value to a 1 and, after selecting the update button 3604, theOFF graphical element 3611 becomes highlighted within the preview GUI onthe client 3520 (and the highlight is removed from the ON graphicalelement 3610), thereby dynamically reflecting the changes entered by theuser. In operation, the attribute value change is first reflected withinthe device attributes 3511 of the virtual device 3510 and is thenpropagated out to the client 3520 via the account channel.

As shown in FIG. 36D the user may select a particular graphic, causingthe preview GUI 3521 to open a field 3620 for modifying the name of thegraphical element (in this case the LED element). In addition, an iconbutton 3621 is provided which generates a window containing a pluralityof selectable icons 3635 as shown in FIG. 36E. Selecting a particularicon 3630 causes the icon to be displayed within the graphical element,as shown at 3640 of FIG. 36F. In one embodiment, the new icon is updatedwithin the presentation definitions 3512 of the virtual device 3510.Depending on the embodiment, this change may or may not be dynamicallypropagated over the account channel to the client 3520, resulting in thenew icon 3641 being rendered in FIG. 36F.

In one embodiment, the updates transmitted over the account channelconnecting the client 3520 to the IoT service 120 are bi-directional. Assuch, user input provided by the user via the mobile app 3522 may beupdated within the virtual device 3510 or real IoT device and reflectedwithin the Attribute Tester dialog shown in FIGS. 36B-C. For example, ifthe user changes an attribute from within the mobile app 3522, theattribute change will be updated within the device attributes 3511 ofthe virtual device 3510 or real IoT device and displayed within theAttribute Tester dialog. In this manner, the user can test the operationof the mobile app 3522 and review the results within the AttributeTester dialog.

This mode of operation is illustrated in FIGS. 36G-H. In particular, inFIG. 36G, when the user initially selects button 3551, the correspondingOFF button 3653 is highlighted and the corresponding attribute value3660 is displayed within the preview GUI (a value of 1 in the example).In FIG. 36H, the user has selected an ON button 3652 from within themobile app 3522, thereby changing the attribute value. The change ispropagated through the device attributes 3511 of the virtual device 3510and displayed within the attribute value field 3660 of the preview GUI3521 (a value of 0 in the example).

Thus, in response to the user choosing to preview a GUI and associatedattributes, the IoT service searches for a corresponding virtual IoTdevice and, if none is found, configures a virtual IoT device with thegiven device attributes and presentation and associates it to the user'saccount. The IoT service then sends a notification on the accountchannel about this new device. Any listener on the account channel mayact on this message, including the mobile app 3522 which will refreshits UI and display a new device on the user's account with the new UI.The user can interact with the preview device, but no real action willbe taken. In one embodiment, if the user closes the mobile app and opensit again, the preview device will be reset to its default state. Theuser can then remove this preview device from their account as theywould for any other device.

A method in accordance with one embodiment of the invention isillustrated in FIGS. 37A-B. The method may be implemented within thecontext of the architectures described above but is not limited to anyparticular architecture.

At 3701, the user chooses to view a preview GUI from within thedevelopment application. At 3702, a search is performed for a devicetype definition that has a specific virtual device class set (i.e.,“PreviewVirtualClass”). For example, an internet-accessible database ofIoT devices may be provided by the user's partner (i.e., the businessentity or individual who designed, manufactured or sold the IoT device).Of course, the underlying principles of the invention are not limited toany particular business arrangement between a user and a partner (and,in fact, the user and partner may be the same entity or individual).

At 3703, if the device type definition does not exist, then a new one iscreated at 3705. If one does exist, then at 3704, the existing devicetype definition is used.

At 3706, the user's account is then searched first for an existingdevice of the aforementioned type. The preview device type of the user'spartner may also be searched for a device that is not associated with anaccount. If found, then at 3707, the existing device is used. If not,then at 3708, a virtual device of the preview device type is created andassociated with the user's account.

At 3709, the uploaded device description (e.g., device attributes) andpresentation are then associated with the preview device. The accountchannel is then notified of the new or updated device at 3710. Anylistener on the account channel such as the mobile app 3522 will receiveand process the notification.

Once the connection has been made, bi-directional interaction betweenthe preview GUI 3521 and the mobile app 3522 may be performed using rawattribute values as discussed above. For example, if an update to anattribute is provided from the preview GUI at 3711, then the mobile appis updated over the account channel at 3712. For example, if the usermodifies the device attribute, the effect of that modification will bepresented to the user within the mobile app (e.g., highlighting adifferent button within the GUI).

At 3713 a determination is made as to whether an update has been made onthe mobile app. For example, the user may navigate and generate updatesthrough the user interface of the mobile app (see, e.g., FIG. 36G-H andassociated text). If so, then at 3714 the update is reflected in thepreview GUI.

The embodiments of the invention described herein allow users such asdevelopers to interact with any device on their account using thedevelopment application 3320. In one embodiment, the developmentapplication 3320 does not communicate through the account channel asother apps do. As discussed above, the development application 3320 mayrender a hierarchical UI of all control groups, their controls and theattributes which allows users to then enter the raw attribute value fora particular attribute and send it to the device. As this value ispropagating through the platform all mobile apps will display thechanges and the device will act on the value sent. In one embodiment,the development application 3320 monitors the attribute history andupdates the attribute values on the preview GUI 3521 to changesinitiated, for example, by a mobile app or on the device itself.

Apparatus and Method for Managing and Configuring Attributes

In one embodiment of the invention, ancillary attribute types areintroduced for managing and configuring the attributes described above.The ancillary attribute types described below include configurationattributes, binding attributes, and grouping attributes.

In one embodiment, an application attribute 3210 as described above ispaired with an ancillary attribute which exposes additionalconfiguration features, referred to herein as a “configurationattribute”. FIG. 38 illustrates one particular implementation in whicheach application attribute 3800 is mapped to a different configurationattribute 3801 which provides additional information related to theconfiguration of the application attributes 3800.

In the illustrated embodiment, each configuration attribute 3801comprises a byte array 3805 where one or more bits represent a flagand/or a value of a feature specified in the application attributes3800. For example, a particular configuration attribute may specify adefault setting for the corresponding application attribute.

In one implementation, some flags may be mutually exclusive. As such, avalidation component of the development application 3320 may check thevalidity of the selections made by the user and/or may remove one ormore selection options when the user has selected a value for aparticular flag (see, e.g., FIG. 42 and associated text below). In oneembodiment, each application attribute and configuration attribute pairare implemented in a stand-alone manner, not affecting other attributes.

In addition to configuration attributes, one embodiment of the inventionincludes another ancillary attribute referred to as a “bindingattribute” which “binds” two or more attributes to one another. FIG. 39illustrates one such embodiment in which binding attributes 3900-3903are associated with Attributes A-D. Each binding attribute 3900-3903indicates the other attributes to which its attribute is bound. Forexample, binding attribute 3900 indicates that Attribute A is bound toattribute C; binding attribute 3901 indicates no current bindings forAttribute B; binding attribute 3902 indicates that Attribute C is boundto Attributes D and A; and binding attribute 3903 indicates thatAttribute D is bound to attribute C.

In one embodiment, the binding allows changes detected in one attributeto be propagated to the attributes with which it is bound, potentiallywithout requiring communication or synchronization with the IoT service120. By way of example, if the IoT device 101 is a smart power outlet,Attribute A may enable or disable power to the socket. A user-accessibleswitch on the socket may also be used to enable or disable power and maybe associated with Attribute B. As such, when the value of Attribute B(the switch attribute) is bound to Attribute A, the outlet turns on andoff and changes the value of both Attributes A and B concurrently whenthe user manually adjusts the switch. Similarly, if the user changes thepower value of Attribute A from the IoT service 120 (e.g., connectingvia a mobile device), the attribute value for the switch also updates inparallel. In one embodiment, the configuration attributes 3910-3913 mayalso store binding information related to the binding of each respectiveAttribute A-D.

In one embodiment, Attributes A-D may be associated with I/O pins A-D onI/O interface 3920, which may be configured to receive input signalsfrom sensors and/or generate output signals to provide notifications.The input signals may be associated with a first set of attributes andthe output signals may be associated with a second set of attributes. Asa result of the attribute bindings 3900-3903, receipt of one or more ofthe input signals may cause one or more of the output signals to begenerated.

For example, IoT device 101 may be designed to monitor shippingconditions within a shipping container. In this embodiment, it isassumed for simplicity that Attributes A-D correspond to I/O lines A-D,which may be configured as digital inputs or outputs. Attribute A ofthis embodiment is associated with input line A which receives a signalfrom a shake or vibration sensor. In operation, when the sensor detectsvibration or shaking of the container above a specified threshold, itsets a latch which generates a signal over input line A.

In this embodiment, Attribute B is used to generate a reset signal overoutput line B to reset the latch if an authenticated reset command isreceived. The resetting of the latch may only be permitted in responseto receipt of an authenticated command from the IoT service 102 or aclient device capable of local user authentication.

Attribute C can be set to cause an LED coupled to output line C toblink, potentially at different rates, when different conditions aredetected (e.g., such as the shaking condition detected from AttributeA).

Input line D, used as an input to Attribute D, is coupled to batterydetection circuitry which generates a signal over input line D when thebattery charge passes under a specified threshold. Alternatively, or inaddition, input line D may be coupled to a temperature threshold devicewhich generates a signal if the temperature within the container islower than a specified threshold for a specified period of time.

In operation, the attribute bindings 3900-3903 shown in FIG. 39configure the IoT device to generate specific responses to these inputs.For example, in response to the input signal from the shake or vibrationsensor on input line A, the resulting change to Attribute A causes afirst change to Attribute C because of the binding of Attribute A toAttribute C. For example, Attribute C may be set to a value to cause theLED to blink at a particular rate and/or using a particular color.

Similarly, a change to Attributed D in response to a signal over line Dcauses a change to Attribute C as a result of the binding attributes3902-3903. The changes to attribute C may be the same as when AttributeA is updated or may be different to provide a more precise indication ofthe shipping conditions. For example, the Attribute D changes may causeAttribute C to be set to a value which causes the LED to blink at adifferent rate or use a different color than when set in response toAttribute A. If both Attribute A and Attribute D changes are detected,then Attribute C may be set to a combined value which causes the LED toblink at yet another rate and/or using another color.

When a recipient receives the container, he/she may then determine ifthe container was subject to adverse conditions based on the blinking(or lack of blinking) of the LED. Depending on the contents of thecontainer, the LED indication may warrant returning the container. Forexample, if the container contains sensitive medical supplies such asinoculations, then it must be discarded if subjected to hightemperatures for a specified period of time.

FIG. 40 illustrates one example of another ancillary attribute referredto as a grouping attribute 4000 which is formed from a plurality ofother attributes (attributes A-D in the example). In one embodiment, thegrouping attribute 4000 is a distinct attribute with its ownconfiguration attribute 4001. In this embodiment, the configurationattribute 4001 contains the references to the individual attributes A-Dthat are grouped together. As described below, the configurationsettings submitted by a user are applied to the individual attributesA-D in accordance with a set of rules (see, e.g., FIG. 42 and associatedtext).

As illustrated in FIG. 41, attribute-based executable code, executed onthe IoT device 101, reads the current values of one or more attributes3800 and the various ancillary attributes including configurationattributes 3801, grouping attributes 4000, and/or binding attributes3900 to determine the operations to perform in response to input signalsreceived over the I/O interface 4110. The operations may includegenerating output signals over output pins of the I/O interface 4110and/or transmitting notifications to the IoT service 120 and/or theuser's client device. In one embodiment, the attribute-based executablecode 4100 comprises an application (or component thereof) executed onthe MCU 3215 (or other type of processor). The executable code 4100interprets the attributes and inter-dependencies between the attributesto perform its operations.

FIG. 42 illustrates one embodiment of the development application 3320which allows a developer to configure attributes 3800, configurationattributes 3801, grouping attributes 4000, and/or binding attributes3900 for IoT applications via the preview GUI (some examples of whichare provided below). In one embodiment, an attribute manager 4200enforces a set of rules 4201 associated with the attributes 3800,configuration attributes 3801, grouping attributes 4000, and/or bindingattributes 3900. For example, a rule may specify certain incompatiblecombinations of attributes or attribute states and/or may specifycertain state changes to attributes or sets of attributes which mustoccur in parallel. In one embodiment, the attribute manager 4200includes a state machine which executes in accordance with the set ofrules 4201 and dynamically provides results to the preview GUI 3521.

In one embodiment, the state machine of the attribute manager 4200includes a validation engine which evaluates the attributes 3800,configuration attributes 3801, grouping attributes 4000, and/or bindingattributes 3900 in view of the rules 4201 to generate validation results4210. For example, if an invalid combination of attributes 3800,configuration attributes 3801, grouping attributes 4000, and/or bindingattributes 3900 are specified, the validation results may produce anerror within the preview GUI. Alternatively, the preview UI 3521 may bedynamically updated such that it is not possible for the developer toconfigure an invalid set of attributes 3800, configuration attributes3801, grouping attributes 4000, and/or binding attributes 3900. Forexample, upon selection of one or more options with respect to theattributes 3800, configuration attributes 3801, grouping attributes4000, and/or binding attributes 3900, invalid options may becomeinaccessible (e.g., greyed out).

Once a valid set of attributes 3800, configuration attributes 3801,grouping attributes 4000, and/or binding attributes 3900 are specified,they may be processed by the IoT device engine 3330, client app engine3331, and IoT service engine 3332 to generate the IoT device profile3340, UX profile 3341, and cloud API profile 3342, respectively.

FIG. 43A illustrates one embodiment of a preview GUI for specifyingconfiguration attributes. In particular, an attribute name field 4300allows the developer to specify an attribute name for the attribute tobe configured and a selectable set of options 4301 are provided tospecify configuration for the attribute. In the illustrated example, theoptions 4301 include “pull up” and “pull down” to indicate the directionof the attribute value in response to a detected condition; “is toggle”to indicate that the value may be adjusted in either direction; “count”to indicate a count value; “latch” to indicate a latched variable (suchas with the vibration latch described above); and “ADC” to specifyanalog to digital conversion (e.g., for converting an analog signal suchas a voltage representing a temperature reading to a normalized digitalvalue).

FIG. 43B illustrates one embodiment of a GUI for specifying bindingattributes. A name field 4310 allows the developer to specify anattribute name for the current attribute. A selectable listing 4311 ofavailable attributes with which to bind is provided. The developer mayselect one or more of the attributes from the listing 4311 to bind thecurrent attribute to the selected attributes within the listing 4311.

FIG. 43C illustrates one embodiment of a GUI for specifying an attributegroup. A name field 4310 allows the developer to specify a group namefor the current group. A selectable listing 4321 of available attributesto be included in the group. The developer may select one or more of theattributes from the listing 4321 to include the attributes in theattribute group. As mentioned, once a set of attributes are included ina group, the end user can only make changes to the attribute valuesthrough the group (i.e., direct access to individual attributes isprohibited). As such, the attribute group ensures that any changes arecoherent across all of the grouped attributes. In addition, attributegroups allow reading and setting all grouped attributes through onegrouping attribute rather than performing multiple write/read operationsto/from multiple attributes.

As mentioned, in one embodiment, a grouping attribute is comprised ofthe actual attribute for the payload paired with a second configurationattribute which stores the additional configuration. The configurationattribute follows the same scheme for storing information as all other(GPIO) configuration attributes as described above.

Embodiments of the invention may include various steps, which have beendescribed above. The steps may be embodied in machine-executableinstructions which may be used to cause a general-purpose orspecial-purpose processor to perform the steps. Alternatively, thesesteps may be performed by specific hardware components that containhardwired logic for performing the steps, or by any combination ofprogrammed computer components and custom hardware components.

As described herein, instructions may refer to specific configurationsof hardware such as application specific integrated circuits (ASICs)configured to perform certain operations or having a predeterminedfunctionality or software instructions stored in memory embodied in anon-transitory computer readable medium. Thus, the techniques shown inthe figures can be implemented using code and data stored and executedon one or more electronic devices (e.g., an end station, a networkelement, etc.). Such electronic devices store and communicate(internally and/or with other electronic devices over a network) codeand data using computer machine-readable media, such as non-transitorycomputer machine-readable storage media (e.g., magnetic disks; opticaldisks; random access memory; read only memory; flash memory devices;phase-change memory) and transitory computer machine-readablecommunication media (e.g., electrical, optical, acoustical or other formof propagated signals—such as carrier waves, infrared signals, digitalsignals, etc.). In addition, such electronic devices typically include aset of one or more processors coupled to one or more other components,such as one or more storage devices (non-transitory machine-readablestorage media), user input/output devices (e.g., a keyboard, atouchscreen, and/or a display), and network connections. The coupling ofthe set of processors and other components is typically through one ormore busses and bridges (also termed as bus controllers). The storagedevice and signals carrying the network traffic respectively representone or more machine-readable storage media and machine-readablecommunication media. Thus, the storage device of a given electronicdevice typically stores code and/or data for execution on the set of oneor more processors of that electronic device. Of course, one or moreparts of an embodiment of the invention may be implemented usingdifferent combinations of software, firmware, and/or hardware.

Throughout this detailed description, for the purposes of explanation,numerous specific details were set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however, toone skilled in the art that the invention may be practiced without someof these specific details. In certain instances, well known structuresand functions were not described in elaborate detail in order to avoidobscuring the subject matter of the present invention. Accordingly, thescope and spirit of the invention should be judged in terms of theclaims which follow.

1. A method comprising: specifying a plurality of attributes for acorresponding plurality of items of data managed in an Internet ofThings (IoT) device and/or an IoT service; associating one or moreancillary attributes with one or more of the plurality of attributes,the ancillary attributes to specify attribute configurations and/orinterdependencies between one or more of the plurality of attributes;evaluating the one or more ancillary attributes to ensure compliancewith predefined constraints associated with the plurality of items ofdata; generating an indication of compliance if the one or moreancillary attributes are in compliance with the predefined constraints;and generating an indication of non-compliance if the one or moreancillary attributes are not in compliance with the predefinedconstraints.
 2. The method of claim 1 wherein the indication ofcompliance or non-compliance is reflected in one or more elements of agraphical user interface of an application development tool.
 3. Themethod of claim 1 wherein the ancillary attributes include one or moreconfiguration attributes, each configuration attribute associated withone of the plurality of attributes and specifying additionalconfiguration data for the associated attribute.
 4. The method of claim1 wherein the ancillary attributes include one or more bindingattributes, each binding attribute to specify interdependencies betweentwo or more of the attributes.
 5. The method of claim 4 wherein theinterdependencies comprise a change to be made to a first attribute inresponse to a detected change to a second attribute.
 6. The method ofclaim 5 wherein the change is made to the first attribute on the IoTdevice without requiring transmission of an update to an IoT service. 7.The method of claim 5 wherein the IoT device comprises a power outletand wherein the first attribute comprises a power attribute to indicatea power on state or a power off state and wherein the second attributecomprises a switch attribute to indicate a switch on state or a switchoff state associated with a manual switch on the power outlet, whereinresponsive to detecting the switch changed between the switch on stateand the switch off state, the power attribute is to automatically bechanged between the power on state and the power off state,respectively.
 8. The method of claim 7 wherein responsive to detectingthe power attribute changed between the power on state and the power offstate, the switch attribute is to be changed between the switch on stateand the switch off state, respectively.
 9. The method of claim 8 whereinthe change between the power on state and the power off state isperformed in response to a command received from the IoT service. 10.The method of claim 1 wherein the ancillary attributes include one ormore group attributes, each group attribute to specify a set of theplurality of attributes included in the group.
 11. The method of claim10 wherein once the plurality of attributes are included in the group,subsequent modifications to the attributes are to be performed onlythrough modifications to the group attribute.
 12. A non-transitorymachine-readable medium having program code stored thereon which, whenexecuted by a machine, causes the machine to perform [[the operationsof: specifying a plurality of attributes for a corresponding pluralityof items of data managed in an Internet of Things (IoT) device and/or anIoT service; associating one or more ancillary attributes with one ormore of the plurality of attributes, the ancillary attributes to specifyattribute configurations and/or interdependencies between one or more ofthe plurality of attributes; evaluating the one or more ancillaryattributes to ensure compliance with predefined constraints associatedwith the plurality of items of data; generating an indication ofcompliance if the one or more ancillary attributes are in compliancewith the predefined constraints; and generating an indication ofnon-compliance if the one or more ancillary attributes are not incompliance with the predefined constraints.
 13. The non-transitorymachine-readable medium of claim 12 wherein the indication of complianceor non-compliance is reflected in one or more elements of a graphicaluser interface of an application development tool.
 14. Thenon-transitory machine-readable medium of claim 12 wherein the ancillaryattributes include one or more configuration attributes, eachconfiguration attribute associated with one of the plurality ofattributes and specifying additional configuration data for theassociated attribute.
 15. The non-transitory machine-readable medium ofclaim 12 wherein the ancillary attributes include one or more bindingattributes, each binding attribute to specify interdependencies betweentwo or more of the attributes.
 16. The non-transitory machine-readablemedium of claim 15 wherein the interdependencies comprise a change to bemade to a first attribute in response to a detected change to a secondattribute.
 17. The non-transitory machine-readable medium of claim 16wherein the change is made to the first attribute on the IoT devicewithout requiring transmission of an update to an IoT service.
 18. Thenon-transitory machine-readable medium of claim 16 wherein the IoTdevice comprises a power outlet and wherein the first attributecomprises a power attribute to indicate a power on state or a power offstate and wherein the second attribute comprises a switch attribute toindicate a switch on state or a switch off state associated with amanual switch on the power outlet, wherein responsive to detecting theswitch changed between the switch on state and the switch off state, thepower attribute is to automatically be changed between the power onstate and the power off state, respectively.
 19. The non-transitorymachine-readable medium of claim 18 wherein responsive to detecting thepower attribute changed between the power on state and the power offstate, the switch attribute is to be changed between the switch on stateand the switch off state, respectively.
 20. The non-transitorymachine-readable medium of claim 19 wherein the change between the poweron state and the power off state is performed in response to a commandreceived from an IoT service.
 21. The non-transitory machine-readablemedium of claim 12 wherein the ancillary attributes include one or moregroup attributes, each group attribute to specify a set of the pluralityof attributes included in the group.
 22. The non-transitorymachine-readable medium of claim 21 wherein once the plurality ofattributes are included in the group, subsequent modifications to theattributes are to be performed only through modifications to the groupattribute.
 23. An Internet of Things (IoT) apparatus comprising: amemory to store a plurality of attributes for a corresponding pluralityof data items associated with the IoT apparatus and one or moreancillary attributes associated with one or more of the plurality ofattributes, the ancillary attributes to indicate attributeconfigurations and/or interdependencies between one or more of theplurality of attributes; and a processor to execute program code tointerpret the plurality of attributes in combination with the one ormore ancillary attributes to implement functions of the IoT apparatus,wherein processor is to: evaluate the one or more ancillary attributesto ensure compliance with predefined constraints associated with theplurality of items of data; generate an indication of compliance if theone or more ancillary attributes are in compliance with the predefinedconstraints; and generate an indication of non-compliance if the one ormore ancillary attributes are not in compliance with the predefinedconstraints.
 24. The IoT apparatus of claim 23 further comprising: anI/O interface to receive at least one input value associated with afirst attribute, the processor to execute the program code to generateat least one output value associated with a second attribute based, atleast in part, on one or more of the ancillary attributes.
 25. The IoTapparatus of claim 24 further comprising: a secure communication channelto couple the IoT apparatus to an IoT device, the IoT apparatus tosynchronize the plurality of attributes and one or more ancillaryattributes with an IoT service.
 26. The IoT apparatus of claim 23wherein the ancillary attributes include one or more configurationattributes, each configuration attribute associated with one of theplurality of attributes and specifying additional configuration data forthe associated attribute.
 27. The IoT apparatus of claim 23 wherein theancillary attributes include one or more binding attributes, eachbinding attribute to specify interdependencies between two or more ofthe attributes.
 28. The IoT apparatus of claim 27 wherein theinterdependencies comprise a change to be made to a first attribute inresponse to a detected change to a second attribute.
 29. The IoTapparatus of claim 28 wherein the change is made to the first attributeon an IoT device without requiring transmission of an update to an IoTservice.